DSP Robotics Support

josevo wrote:Ruby should not be used for creating the synchronisation part of sequencers as you may notice in this example

Thank you so much for the improvements
I'm sorry but I didn't understand your remark. If we can't use ruby for syncing (why?), what else can we use? or you're just saying that flowstone can't do it in general?

kortezzzz wrote:

josevo wrote:Ruby should not be used for creating the synchronisation part of sequencers as you may notice in this example

Thank you so much for the improvements
I'm sorry but I didn't understand your remark. If we can't use ruby for syncing (why?), what else can we use? or you're just saying that flowstone can't do it in general?

Sorry for my poor english, I only speak French and Spanish.

Regarding Flowstone, I didn't discover a single thing that can't be done with it, well, except low-level pixel processing.

Anyway, let's start a reduced explanation:

1. By convention, the MIDI song position reference is called PPQPos (or PPQNPos=Pulses Per Quarter Note Position)
and FS includes a component for that (see the image below).



2. The problem is that Ruby editor does not include a stream input accepting that signal, although it's not a downside at all.

3. We can anyway use DSP (or Assembler) component, in fact, they are more appropriate for that, and much faster processing streams. Another option is to use the "Mono To Frame" (not the "Frame Sync") primitive, but I didn't test it heavily.



Resuming: Try to use Ruby and non stream components for intensively low/medium event processes where time accuracy is not crucial at a millisecond level, e.g. GUI controls, menus, midi inputs from instrument, array updates, ... and use DSP for audio process in real time, including for DAW message processing.

Finally, some time ago, I uploaded a simplified example of a synchronisable sequencer: http://www.dsprobotics.com/support/download/file.php?id=11637

Hope it helps!

josevo wrote:2. The problem is that Ruby editor does not include a stream input accepting that signal, although it's not a downside at all.

It doesn't need one. In a DAW, and in the Flowstone editor, when ASIO out is used, Ruby is always sync'd to audio. More precisely, it will always work in the current audio buffer. It should not have much issues being precise to the millisecond. I know of an arp done in Ruyb, that works precise and uses scheduled methods (methods that are executed at a specific timestamp). There's mono-to-frame to convert a specified number of samples from blue to RubyValue, this can be used to access blue data in Ruby.

While your general advice is valid, this specific case is the exception. DSPR spend quite some time on making sure, Ruby is sync'd, so it can be used for situations, where timing down to milliseconds or less is important.

EDIT: I forgot to mention the Frame Sync prim, which you can additionally use to trigger the RubyEdit EXACTLY when the audio outs request the next buffer. This is less interesting for MIDI, but very important for the fx chain, for example.

Thank you so much, Tulamide!

I didn't find enough information and working examples about "Frame to Mono" so I was not sure it was a good solution. The concept of using a large buffer for checking a simple clock or song position seemed too slow and complicated to me, but it works.

I appreciate your corrections.

Thanks for your input, guys. Always glad to read interesting discussion. Just didn't completely understood:
Is Ruby midi resolution can go fast enough to compete high range hardware arranger organ or a modern DAW?

For instance, Yamaha's PSR arrangers have 1920ppq. According to yamaha's forum, anything under 480ppq can not be considered as PRO level sequencer. Old yamaha arrangers from the 80' reached to 120ppq. Where do we stand with flowstone? Can flowstone go any better than the current state with future updates?

Maybe it's just me not really understanding the whole ppq thing correctly, so I'm sorry.

kortezzzz wrote:Thanks for your input, guys. Always glad to read interesting discussion. Just didn't completely understood:
Is Ruby midi resolution can go fast enough to compete high range hardware arranger organ or a modern DAW?

For instance, Yamaha's PSR arrangers have 1920ppq. According to yamaha's forum, anything under 480ppq can not be considered as PRO level sequencer. Old yamaha arrangers from the 80' reached to 120ppq. Where do we stand with flowstone? Can flowstone go any better than the current state with future updates?

Maybe it's just me not really understanding the whole ppq thing correctly, so I'm sorry.

This is mostly marketing whoop. Even modern DAWs don'T go that deep. For example, FL Studio runs at 96 ppq, all other DAWs I know of at 960 ppq.

ppq = pulses per quarter. Consider a pulse as a trigger. 96 means per quarter beat the daw can trigger midi messages 96 times. If you create a sequencer that provides a 4/4 signature and one bar, and allow quarter note positions only, your sequencer needs just 1 ppq. For sixteenth it needs 4 ppq. Do the calculation yourself, what you get with 1920 ppq. Hi ppq is improtant for the DAW only, as it needs to record midi as you play it, unquantized. But no human on this earth will tell apart a delay of 1/umphteenth of a note (at bpm 120, we're talking of 0.5 seconds per beat, making a 16th note last 0.125 seconds or 8ms for a 64th note)

tulamide wrote:This is mostly marketing whoop. Even modern DAWs don'T go that deep. For example, FL Studio runs at 96 ppq, all other DAWs I know of at 960 ppq.

ppq = pulses per quarter. Consider a pulse as a trigger. 96 means per quarter beat the daw can trigger midi messages 96 times. If you create a sequencer that provides a 4/4 signature and one bar, and allow quarter note positions only, your sequencer needs just 1 ppq. For sixteenth it needs 4 ppq. Do the calculation yourself, what you get with 1920 ppq. Hi ppq is improtant for the DAW only, as it needs to record midi as you play it, unquantized. But no human on this earth will tell apart a delay of 1/umphteenth of a note (at bpm 120, we're talking of 0.5 seconds per beat, making a 16th note last 0.125 seconds or 8ms for a 64th note)

Thanks for the answer, tulamide, as always. So where we stand with flowstone? Just curious. What's it's limit before it loses the absolute accuracy?

kortezzzz wrote:Thanks for the answer, tulamide, as always. So where we stand with flowstone? Just curious. What's it's limit before it loses the absolute accuracy?

I thought I made it clear that the accuracy comes from the DAW, not Flowstone. Flowstone is just a VST plugin, it has never been a DAW or even intended to be one. All timing information comes from the DAW, with Flowstone reacting to it. Due to double buffering, there is plenty of time to calculate a massive amount of things. How much exactly is dependend on the DAW, its resolution and its buffer settings.

tulamide wrote:

kortezzzz wrote:Thanks for the answer, tulamide, as always. So where we stand with flowstone? Just curious. What's it's limit before it loses the absolute accuracy?

I thought I made it clear that the accuracy comes from the DAW, not Flowstone. Flowstone is just a VST plugin, it has never been a DAW or even intended to be one. All timing information comes from the DAW, with Flowstone reacting to it. Due to double buffering, there is plenty of time to calculate a massive amount of things. How much exactly is dependend on the DAW, its resolution and its buffer settings.

Ok, got it now. Thanks tula

Josevo,
Tested your improved arp and it's really a great concept but when I play chords, I get stuck notes on chord switch from the previous played chord. Any ideas what can be wrong?

kortezzzz wrote:Tested your improved arp and it's really a great concept but when I play chords, I get stuck notes on chord switch from the previous played chord. Any ideas what can be wrong?

I discovered more issues so I changed a lot of things but I couldn't test the VST sync in a DAW.