how to send Midi Message

[Walter Sommerfeld]

Well - now always these little problems...

I cannot exit this each do loop
It always run's until it's end.

The count shows immediately the max events.length!

It doesn't matter whether i use catch/throw or break...

Is there a trick with raising an error or something else?!

[tulamide]

I'm not 100% sure, but here are some thoughts:

(1) break would have been sufficient. That both don't work, seems to point to '@plays' being the cause.
(2) each is a closed loop. It will be executed exactly at the time it is called. There is no connection to the external world (which means everything outside of 'when 1')
(3) if @plays happens to be an input, then .each will not be aware of any changes to the input until .each is done and Ruby is given a chance to peek at the inputs again.
(4) In case (3) is true, you need another way to loop through (for example scheduled inputs/methods), so that @plays is checked for its current state in each iteration.

[Nowhk]

Yes, there is. The critical part is the timing. If you are recording premade sequences from the DAW, then you can use the ppq info for the timing. If not, you can only use Ruby's timing, which is reliable down to 10ms.

Ok, I am on this again Ruby works at 100 Hz (10ms=100 times per second) and MIDI is sync with PPQ.

If I have a PPQ of 96 ticks per quarter (beat) and I play my DAW at 120BPM, I have 96x2=192 ticks per second.

Using tick as snap/resolution, hypothetically I can't play a MIDI note each tick, since Ruby is limited to 100Hz (192>100), and this will eat lot of CPU; but this is irrelevant, since a MIDI note for each tick would be too many notes in a second, musically.

Let say I switch the snap to a resolution of 1/4 step (i.e. 1/16 beat; which could be appropriate for a score): It will process 32 MIDI messages in a second, which is good for Ruby (32<100).

How would you sync this PPQ with Ruby? I mean: how would you output 32 notes in 1 second using Ruby timing if it works in "second"?

Code: Select all

# 1/32=0,03125
output 0,@note,t + 0,03125


this way? FlowStone will automatically translate this timing (in second) in PPQ value (tick) when it reaches back the DAW and play a VST? It will lost lots of ticks if the Ruby precision is around 10ms (i.e. 0,01).

In this specific case for example, the ticks between 0,03 and 0,03125.

[Walter Sommerfeld]

(3) if @plays happens to be an input, then .each will not be aware of any changes to the input until .each is done and Ruby is given a chance to peek at the inputs again.
(4) In case (3) is true, you need another way to loop through (for example scheduled inputs/methods), so that @plays is checked for its current state in each iteration.

scheduled inputs/methods => Ahh - i see... had this in an older project - will try my best here...

Thanks 4 the hint!

[Walter Sommerfeld]

=> only the Ticker - Custom' modul as an example i'm totally lost with this 'scheduleMethod'

Scheduling Methods
You can also schedule method calls using the scheduleMethod method.
scheduleMethod methodName, arg1, arg2, … , time
Where methodName is a string specifying the name of the method, arg1, arg2 etc. is a list of argument
values to pass to the method (you don't have to supply any) and time is the time that you want the
method to be called (use the time method to get the time now in seconds and offset from that)

[tulamide]

Scheduling a method is straight forward. For this example, create a boolean input for your RubyEdit and link it with a boolean prim set to false. Then paste the following code:

Code: Select all

def event i, v, t
   if i == 0 and v == true
      watch "event", t
      scheduleMethod "checking", t + 2
   end
end

def checking
   watch "method", time
end

Now switch the boolean prim to true and wait two seconds. As you can see, the event occured right on time, but the method is executed 2 seconds later (t + 2).

For your task I would go with scheduled inputs. I've attached an example.

[Walter Sommerfeld]

Thanks again Tom - will be a long night

Hope i get no Midi Timing probs...

Keep on Doing!

=> Short Report...
Got it now

But this idea of breaking into the playing loop is really bad...
How could i know when to stop and which notes Off 2 send?!
Could do this with an array and send the corresponding ones...
a way to heavy task now - only wanted a quick record looper
for some controller CC's/Notes => this works perfectly, so - I've done it!

[tulamide]

=> Short Report...
Got it now

But this idea of breaking into the playing loop is really bad...
How could i know when to stop and which notes Off 2 send?!
Could do this with an array and send the corresponding ones...
a way to heavy task now - only wanted a quick record looper
for some controller CC's/Notes => this works perfectly, so - I've done it!

This almost escaped my notice. A new post is better if more than a few hours moved
Yes, you're right. It's as always, as soon as you try to take over control against the DAW, you'll be in trouble.
But I'm glad that the original idea works. Good job!

[Tronic]

Ruby is limited to 100Hz

Not true, when the audio is active.
Have you read the FS Manual at p.148?

Here is what I can read.
Scheduling Events
Clock Accuracy
The schematic clock runs at 100 Hz. Unlike the Tick components which are not time precise due to
their use of Windows timers, the Events system uses a different timer which is much more accurate so
each 10 millisecond tick should occur precisely on time.
If you have any of the DirectSound or ASIO primitives in your schematic and these are switched on
then the clock will automatically switch to run in sync with the audio processing. You can then
schedule events to occur with sample precise timing within any audio frame.

[tulamide]

Ruby is limited to 100Hz

Not true, when the audio is active.
Have you read the FS Manual at p.148?

Here is what I can read.
Scheduling Events
Clock Accuracy
The schematic clock runs at 100 Hz. Unlike the Tick components which are not time precise due to
their use of Windows timers, the Events system uses a different timer which is much more accurate so
each 10 millisecond tick should occur precisely on time.
If you have any of the DirectSound or ASIO primitives in your schematic and these are switched on
then the clock will automatically switch to run in sync with the audio processing. You can then
schedule events to occur with sample precise timing within any audio frame.

I told him the very same weeks ago, Tronic. That's why it feels like being Sysiphos when trying to help Nowhk. Maybe it is because Flowstone for FL Studio doesn't have those primitives (just audio out), which makes him ignore this bit. But I would bet the sample precise timing is the same with an active audio connection to FL.