trigger from stream

[gvalletto]

Hi all. I want to get a trigger from an event occured in stream data. To do this, I am not want to use "mono to float" primitive. I suppose it can be made with Ruby, but I am just a beginner in Ruby.

For example (see the attached scheme, it does not work) I want a trigger when the LFO has a zero value. How to make it?

trigger from Ruby.fsm

(20.47 KiB) Downloaded 800 times

[gvalletto]

... sorry by the delay, I have just attached the scheme in the first post.

[Spogg]

I don’t know the answer but I’m curious as to why you don’t want to use M2F primitive.
If it’s about timing accuracy, once you enter the green world that goes out of the window anyway…

Cheers

Spogg

[tulamide]

You need to be more precise. Do you want a specific value to be 0, or the whole frame? Also, since we're dealing with single precision floats, you will rarely (if at all) get exactly 0, so additionally you have to define a range to be considered 0 (read: almost zero).

Some help

Code: Select all

sum = v.to_array.reduce(:+) #Sums all values in the array
avg = v.to_array.reduce(:+)/ v.size #getting an avg value from the array
val = v.to_array[12] #getting a specific value from the array (here the 13. with index 12)

[gvalletto]

Hi all,
I am building a synth that includes a step modulator (in the scheme, replaced by a saw LFO) and a wave player. The step modulator has a stream output, and the wave player has loaded a crash drum sound.
I want the crash drum sound to be triggered when the saw LFO gives a zero value.
I made that with M2F but is´nt precise. even tough I can to use with a ticker with enough high rate, the windows timing is not precise for this use. Also, high rates in this case are a problem itself. By that reason I think to build a Ruby module that generates just 1 green trigger, that occur when an event "equal zero" occurs. That eliminates the undesired ticker and raises the accuracy due the Ruby timing nature.

[Spogg]

I would be inclined to do the whole thing in stream.
Not only would it be simpler but I think you would still hit timing issues if you rely on anything in green to provide an accurately timed trigger. If something else is going on in green at any time, it will affect the timing of the green trigger in an unpredictable way.

The fact that Ruby can put out a trigger with ±10mS accuracy makes no difference once it gets outside the Ruby Edit. I think ...

Cheers

Spogg

[gvalletto]

Yes Spogg, and it´s easy for me to make a comparison in DSP code, but
first, it need continuous triggers when that comparison is converted to green (means too much triggers).
Second, the 50 ms in not a big problem. The big problem is those 50 ms between triggers are just an average. Try to put a ticker 100 or 25, then divide it and trig a midi note event. Yo will expect to hear a constant and rhytmic repetition of notes, but reallly you will hear drifts in time...
As I told, I am just a beginner in Ruby, but I read that, despite the 10 ms, it is more accurate with times. Also, perhaps a Ruby code may to shoot a trigger just one time, made when a comparison is true. The Ruby Gurus will say whether it is possible... and easy...

[tulamide]

I don't think it is a project suitable for a beginner, but you could try.

A few facts:
When working with frames, you get exactly the buffer of samples, that your output is using. For example, I use ASIO4ALL with a 720 buffer, so I get a frame of 720 samples. I think you didn't realize that yet. It is NOT working like mono or polystream where you work on one sample at a time.

Those frames are sync'd of course. You get them exactly when they have to be filled by Flowstone. You also are responsible for delivering them in time, or else there will be dropouts.

The audio system uses double-buffering. That introduces latency. You are working one frame ahead.

Ruby is not as fast as C. It is an interpreted language. That means all the audio specific tasks you do in Ruby are way more CPU intensive than DSP/Assembler.

And again: You are working with single precision floats. You are not guaranteed a specific value! So, when looking for exactly 0, you might miss a lot of triggers because instead of 0 they are a tiny bit off (almost 0).

[martinvicanek]

One argument against doing it in code or asm is you can't send MIDI commands. Unless I missed something.

[gvalletto]

I don't think it is a project suitable for a beginner, but you could try.

A few facts:
When working with frames, you get exactly the buffer of samples, that your output is using. For example, I use ASIO4ALL with a 720 buffer, so I get a frame of 720 samples. I think you didn't realize that yet. It is NOT working like mono or polystream where you work on one sample at a time.

Those frames are sync'd of course. You get them exactly when they have to be filled by Flowstone. You also are responsible for delivering them in time, or else there will be dropouts.

The audio system uses double-buffering. That introduces latency. You are working one frame ahead.

Ruby is not as fast as C. It is an interpreted language. That means all the audio specific tasks you do in Ruby are way more CPU intensive than DSP/Assembler.

And again: You are working with single precision floats. You are not guaranteed a specific value! So, when looking for exactly 0, you might miss a lot of triggers because instead of 0 they are a tiny bit off (almost 0).

Thanks Tulamide, your explanations are clear. Regard to the "single precision of floats", no matter for me in this case because I will use integer values from a stream step LFO made with DSP code. I the schme I put a saw LFO just by the example, but really I will use integer values. What do you think about?