posted 02 October 2013 05:12            

I want to play a sample by e.g. !keydown, process it with reverb and then reverse it (play it backwards). I tried to accomplish something with memorywriter / reader but i can't figure out what to put into trigger and captureduration to make it work. any suggestions?
is it maybe even possible in real-time?

posted 02 October 2013 06:37            

Say that the duration of the event plus its reverb time is 5 s. Then, in parallel with the MemoryWriter you could have a Sample that is triggered with (1 = (!KeyDown ramp: 5 s)). The Sample would have SetLoop unchecked and Reverse checked.

posted 03 October 2013 01:56            

Actually (1 = (!KeyDown ramp: 5 s)) didn't work but !KeyDown ramp: 5 s did.

Since CaptureDuration is not a HotValue is there a workaround to change the CaptureDuration somehow? The reason I want to do this is I want to change the playback rate of the sample and perform some delay processing as well and it would be very comfortable to have the CaptureDuration value somehow adapting instead of changing it manually in the sound editor... or at least by changing only 1 parameter field in the sound editor and then recompile. I don't mean to change the parameters in realtime but I would like to make some changes and then trigger again with a different CaptureDuration. Is it possible?

Finally I feel like touching a border of the Kyma Universe - maybe I should turn around and see what's on the other side

Greets,
Gustl

posted 03 October 2013 13:10            

FrontNBack.kym

Attached is a rough sound that acts like there is a live control over the duration.
The duration remains the same but the record and playback sounds only use the part of ram that you set with the !Dur control in seconds.

You could make it better, by gating the signal going to the memory writer rather than shortening the input sample players play length. You could also add a bit of smoothing to the gate edges and adjusting the lengths so that the change over cross fades and removes the clicks.

I'm sure you can work that one out, if not let me know?

Hope it helps

posted 04 October 2013 03:55            

I used ((!SampleLength / !FreqScale) + !ReverbTime) instead of !Dur so I can specify my sample length in the VCS and the total duration of the processed sample will be correct. works like a charme

only one question: why is there a "-0.5" in the gate parameter field of the sample?

posted 04 October 2013 11:54            

Glad it helped. The output of the ramp rests at one and when triggered goes to zero and starts rises back up to one for the given time. This means that without any off set the off time holding off the trigger would only be a split second. I could have subtracted 1, meaning the ramp output would rest a zero and jump to -1 and ramp back, but this would never cross zero and would never trigger.

I could have subtracted 0.999 to make sure it crosses zero, but then the timing will be out by a small fraction. Instead I subtract 0.5 so it starts at 0.5 jumps down to -0.5 and ramps back up, crossing zero at half the ramp duration. I then double the duration to compensate.

So basically it there to ensure that it crosses zero exactly when I want it to.

hope this makes sense

posted 07 October 2013 13:36            

Did it work such that you were waiting the minimum amount of time before you heard the revers play back. I think that may be I didn't explain it correctly seeing the picture on your post.

You show

!Play ramp: ((((!SampleLength / !Verispeed) + !DelayLength + !RevLength)) *2)-0.5 s

and not

(!Play ramp: (((!SampleLength / !Verispeed) + !DelayLength + !RevLength) *2) s) -0.5

The idea was that the -0.5 would offset the ramps output so that it centered around zero but your formula has subtracted 0.5 seconds from the ramp time but has no offset. No offset means there is no hold off time. If !Play is the same hot param that is firing the input sample, then the reverse play back will start straight away but will play what was recorded last time you did it (until you get to half the time where it will switch from the old to the new recording). Remember the recording is going from left to right and the play back is going from right to left and they will meet half way.

It may well be that it is the same recording every time so it wouldn't matter, (but not if you are changing the pre processing on the recorders input). I think you would get the same results if you just put !Play in the gate field instead of the formula. It would work but you would need to trigger it twice to hear what you wanted to hear, as the first trigger would play some of what was recorded the previous time.

All in all, the way you have it now may be a more usable object as it always plays something when you hit !play without having to wait, even if the thing it is playing is not based on your current settings.

I hope this makes sense.

posted 07 October 2013 14:27            

Did it work such that you were waiting the minimum amount of time before you heard the revers play back. I think that may be I didn't explain it correctly seeing the picture on your post.

You show

!Play ramp: ((((!SampleLength / !Verispeed) + !DelayLength + !RevLength)) *2)-0.5 s

and not

(!Play ramp: (((!SampleLength / !Verispeed) + !DelayLength + !RevLength) *2) s) -0.5

The idea was that the -0.5 would offset the ramps output so that it centered around zero but your formula has subtracted 0.5 seconds from the ramp time but has no offset. No offset means there is no hold off time. If !Play is the same hot param that is firing the input sample, then the reverse play back will start straight away but will play what was recorded last time you did it (until you get to half the time where it will switch from the old to the new recording). Remember the recording is going from left to right and the play back is going from right to left and they will meet half way.

It may well be that it is the same recording every time so it wouldn't matter, (but not if you are changing the pre processing on the recorders input). I think you would get the same results if you just put !Play in the gate field instead of the formula. It would work but you would need to trigger it twice to hear what you wanted to hear, as the first trigger would play some of what was recorded the previous time.

All in all, the way you have it now may be a more usable object as it always plays something when you hit !play without having to wait, even if the thing it is playing is not based on your current settings.

I hope this makes sense.

posted 29 October 2013 14:33            

Your idea about a forum section dedicated to "Sound for Picture" may have sounded like a good idea, but I wonder if you have really thought it through. I believe that there are too many sections already in the forum and it make searching for something you may have seen in the past, (or even something you have not seen), very difficult to find. It is not that clear cut as to which of the first 4 sections in the private forum a question or a suggestion should go.

By introducing yet another section dedicated to "Sound for Picture" just increases the ambiguity and most of the time hints on how to use Kyma for "Sound to Picture" will nearly always lend themselves to sound for everything else and vice versa. I suspect that by having a private section, you will find you gain nothing, but stand to loose a lot.

Not that my input is all that important, but I have seen posts being added to what has now become a private section, but I have no idea what they are, or if I could help, because I am excluded from that part of the forum. Even if I was given access, I am sure there are many other people whose expertise you will be missing out on. Also I would not be prepared to give input to what was a limited elitist group, and was not shared with the whole Kyma community.

I'm sure you have good reasons for having a "Sound for Picture" section, but I do hope that this is not the start of a trend, where we begin to see a "Sound for FX" "Sound for Music" "Sound for Research" etc. sections appearing. If this happens I can only see it as being a change for the worst, where everyone looses out.

I hope this makes sense

Thanks

posted 29 October 2013 15:16            

The Sound for Picture forum was initially open to the public but was starting to get spam so we switched it to private this morning (but in so doing we inadvertently barred everyone! Clearly a "totally private" forum would not be conducive to conversation And it was not our intention.

In the meantime, sound-for-picture discussions would be very welcome in the Tips and Techniques section. (while we continue to fight with the BB settings)

posted 29 October 2013 22:42            

ps. by the way, what's the difference between "Support FAQ" and "Kyma Support". Is there any reason why these sections are not merged? Or is it only me who's confused?

[This message has been edited by gustl (edited 29 October 2013).]

posted 22 November 2013 02:37            

Kyma is a system of beautiful and elegantly separated out abstractions, so it'd be nice to apply similar abstractions around the forums where it fits.

One of the other things that Kyma seems to exemplify is "standing the test of time" ;-) Experimentation and seeing what things are like rather than using rules before rules appear naturally as a kind of evolution. I really like that.