posted 06 October 2004 05:04            

If you take a look at Petes microsounds you will find that where every possiable I've made the control be a sound input (without the one milli second limit). This does give the problem that any one who uses them must put "constant" sounds into the inputs that they don't need to be at full sample rate, which makes messy diagrams and also uses much more DSP power. They are more like raw building blocks such the you can make a lot of sounds similar to those in kyma's own prototypes, but it takes more modules and more hardwork to do it. But you do have the advantage that you can manipulate whats going on inside and nearly always have sample rate control. If you have a specific use in mind, maybe you could describe it and I'll see if the microsounds could help.

posted 06 October 2004 06:01            

I think the paper was by Dennis if my memory serves me right but I think the main points were that if you paste a sound into a hot parrameter you add 1ms delay to that control, but only when pasted into hot parameters. i.e. you can paste a sound into a sound input and then paste that sound into another sound input as many times as you like and you get no additional latency what so ever.

posted 06 October 2004 06:51            

forKurt.kym

So for realizing it we had one guy building an external box which can detect the video sync signal and switch for that period to another input. This other input is a 25 kHz sine wave oscillator which currently is Kyma on output 4. By the way, the capybara has to run on 96K for this patch.
For running the patch at your place I captured ten seconds of the input, the video signal with the 25K sine instead of the sync pulses. You find it here: http://www.audionomio.de/stuff/forKurt.wav (about 2.6MB)
Once inside Kyma the signal gets filtered on 15K and 30K and some lowpass to get rid of some strange halfsamplerate behaviour. In parallel thereīs the detection unit for the 25K signal which triggers 2 ms delayed the memorywriter. Currently the captureduration has to be 16 ms for reasons I donīt fully understand. Apparently, when itīs longer it already captures the next 25K burst.
This sample can be read out looped with varying rates. It will be always slower than the original because 16 ms have to become 20 ms to get the desired continuos sound. As long as the sample is read it may not be overwritten, otherwise I get nasty clicking. So I programmed two alternating memorywriters which only write one sample while itīs not being read.
The frequency slider is the denominator for the playback rate.
The !Readout I programmed to make sure that I really get 50Hz of the camera. Itīs all PAL, b.t.w.

It works actually quite well, but I have two basic problems which I *have* to get rid of:
1) Thereīs a clear bump and/or click at the loop point. Very clear audible at playback rates of !Frequency > 10.
2) When playing back at high speed (!Frequency = 1.3) I get some periodic phase shifting of the memorywriter triggerinput or whatever. Every 10s or so the sample will also capture some bits of the 25k burst. It is slowly getting in and out. And I really don't know how come that.

There are also some D/A weirdness things which are already adressed with Kurt (thatīs why the name). I get randoml channel swaps. Would be interesting to know if itīs only my particular system.

Thanks for offering your help. I hope Iīm not overusing it this way but I really donīt know how to continue with it. The only idea I have is trying out the LCK for zero-crossing and crossfading but that would only adress problem one, I guess.

I hope all this makes sense. Thanks already for investigating!
Best regards,
- Mathis

[This message has been edited by mathis (edited 06 October 2004).]

posted 06 October 2004 10:25            

How about taking a slightly different approach? Set the MemoryWriter to cyclically record (rather than triggering the recording). Then mix two different enveloped Waveshapers to play back the recorded sample out of phase with each other so that when one envelope is fading out, the other envelope is fading in. That would give you the crossfade you describe.

You would have to design an Index into the Waveshapers that skips over the sync signals and plays more slowly through the rest of the signal (to fill in the gaps). You could probably use an InputOutputCharacteristic to design this nonlinear index. You might even be able to just design a wavetable that has the proper index function in it. Then you could use an Oscillator to generate the Index at the desired rate.

Take a look at the PolyphonicPitchShiftDelayLine Prototype (give it a constant Interval value and expand it to see how it is constructed). This would give you a starting point for constructing the cross-fading Waveshapers and also for playing them back at different rates. What remains would be to create the nonlinear index into the Waveshaper for skipping over the synch intervals.

posted 07 October 2004 08:22            

It may be some time before I can get in front of a machine to tri it out but in the mean time you could try this out.

Re:Your trigger at sample rate problem.

If you instead use Step Writer form petes microsounds, this modules lets you write (or not write) to memory at any point you choose. Therefore if you used this instead of memory writer and put a constant with value one in the "write" input and put an "up/down counter" (also from petes microsounds) in its index input. You could then use this in it's place. In the Up/down counter you should make sure that the NoOfSamps is the same as the NoOfSamples in the step writer, you should put a constant with value one in the CountUp input , and a constant with value zero int the CountDown input and the reset input becomes your new trigger (at sample rate). NoOfStepsUpwards and NoOfStepsDownwards should both be value one and the two other fields should be 0.

Also as far as playback is conserned if you use a fullramp waveform in a sample player or oscilator as an index then you have the problem that if you don't have interpolation on then you can get odd steps in the ramp but if you do have interpolation on then the last step can be interpolated with the first step and read a sample somewhere in the middle of your stored signal as the loop happends, causeing a click. if instead you use one of the ramp generators in petes microsounds you don't get this problem.

Let me know if this helps.

posted 08 October 2004 15:28            

I exchanged the memory writers with your stepwriters and my phase problems are gone. Now I only have to find a better solution for the loop point. But the track now is a very good one. Iīm very confident again.
Thanks so much for sharing your efforts! I well appreciate that!

Any signs of the paper? Since this problem was caused by the 1kHz control signal rate it is necessary to learn as much as possible about the internal timing of the Capy. Of course, for most applications there will be no problems, but here Iīm working near controlsignal rate.

posted 10 October 2004 07:23            

in the Polyphonic Pitch Shift Delayline you use oscillators for crossfading. I was first surprised that your audio signal is fed into the oscillator via a hot paramtere field, namely Envelope. I thought this must result in a frequency reduction to 500 Hz. Then I read in the help file: "For full sample rate amplitude envelopes, erase the 'L' that automatically appears after the name of the pasted Sound."
Is that valid for all hotparameter fields in every module?

Bests,
- Mathis

EDIT: answered here: http://www.symbolicsound.com/cgi-bin/forumdisplay.cgi?action=displayprivate&number=7&topic=000017
it is an exception.

posted 10 October 2004 07:49            

is it possible to trigger/synchronize your ramp generator?

Bests,
- Mathis

EDIT: OK, answer given myself. I overlooked the setableRamp modules. But what is the difference between setableRamp and setableRamp2 ?

posted 12 October 2004 08:44            

Thanks for the feedback at always helps when you know your work has a worthwhile usage.

SettableRamp had a fault when you used zero in some of the parramitors. You should always use SettableRamp2, I just left the first one there incase people had already used it in there sounds. By the way the UpDownCounter also can act as a triggerable ramp generator aswell.

You can also use a Waveshaper as a memory reader instead of sample players etc. this way you can feed it's index with these ramps/counters and have sample rate control over the playback. This way you can make the loop jump back exactly when you want without it playing that odd interpolated sample half way through the jump.

The ramps and counters are optimized to work with the Waveshaper module and in turn the StepWriter is optimized to work with the ramps and counters.

posted 13 October 2004 05:24            

BTW The Hot parameter field named Envelope in the oscilator sound used to be the one and only field in the whole of Kyma that could have a sound pasted into it and would then work at sample rate, but now the new VCF module also has hot pastable sample rate type fields. But I think they're the only ones.

BTW2 I notice that you wanted to alternate reading and writeing between two different RAM tables. The petes modlules logic stuff may help you here aswell, as they all work at sample rate.

If you look at the module named "Toggle" (and asuming that your triggers are zero or less changing to one or greater than zero), then the first trigger into this module will make the output go to one and the second triger will make the output go to zero. The third will make it go to one and the fourth , to zero again and so on. Therefore if you put a Gate ToTrigger module on the output you will get one output trigger for every two input triggers. If you also put the toggle modules output into an inverter (use an AsLogic module with value one in the invert field) and then feed that into a GateToTrigger module you will get all the other triggers ( the ones missing from the first).This way you can have two seperate trigger streams alternating between the two outputs and its all done at sample rate so there's no additional delay. Maybe this could be used to trigger the ramps feeding your readers and writers.

hope it helps.

posted 13 October 2004 18:32            

DSPEvaluation.kym

thank you very much for your georgious help again.
My Sound is working now in more or less every aspect it should do. However..... I run terribly out of DSP power. I mean just today I ordered two more cards but I just found out that 12 DSPs still wonīt be enough. Iīd need 18 as far as I can see.
In the end there will be five cameras and up to now I experimentated of course only with one. Now 3 DSPs are very moderatly busy with one camera, about 30% I would say. Now I thought/hoped of course that Kyma will be able to stack another camera on top of these three DSPs usage. Unfortuantly it seems to be not possible. I need for every new camera another three DSPs.

Carla, Kurt or Pete, would you please be so kind to investigate if you see any possibilities for more DSP modesty? Otherwise Iīm in deep shit basically...

Itīs a fun patch now anyway. What I post here is a build for two cameras. It runs on 8 DSPs on 48 KHz. A capture of me filming Zebra patterns you can find here: http://www.audionomio.de/stuff/Camera48K.wav

We will use it not only to playing back directly the videosignal of the camera but also for amplitude modulating instruments. I put in a drone sound for simulation. You have to switch "Modulation" on and set the Frequency slider to a high value (Itīs the denominator for playback rate).

posted 14 October 2004 10:52            

UserCodeForMathis.zip

One more thought... If you don't need the OscilloscopeDisplay for debugging, you could take that out of the signal flow as well.

posted 16 October 2004 02:55            

There will be a more official announcement, but just for the record: The performances will be on November 13th and 14th in Ijsbreker, Amsterdam.

posted 25 October 2004 15:19            

DSPEvaluation.kym

But there is another *very* significant problem now. Please look at the newly attached sound "DSP Test 2". The patch uploaded here before contained the processing for two cameras. One camera-process needs three dsps, two need six dsps. So I thought three of them need 9 and so on. But three cameras donīt even run on my 12 DSPs (proud owner of 12 DSPs now )
There seems to be possible maximum of stepwriters/memorywriters or something. Could you please figure out where that comes from?

Thanks,
- Mathis

posted 25 October 2004 19:12            

1. Add a TimeOffset of 1 samp to the Kamera 2 branch (between Kamera 2 and Output4) and a TimeOffset of 2 samp to the Kamera 3 branch (between Kamera 3 and Output4). This seems to make it schedule on 7 DSPs for me.

2. See if you can get your cameras to be synchronized so that you can detect the sync pulse of one of them and use that result for all of the cameras.

posted 26 October 2004 03:38            

quote:

---

Originally posted by SSC:
1. Add a TimeOffset of 1 samp to the Kamera 2 branch (between Kamera 2 and Output4) and a TimeOffset of 2 samp to the Kamera 3 branch (between Kamera 3 and Output4). This seems to make it schedule on 7 DSPs for me.

---

Come on, this is AMAZING!