How "draw" method is executed from Stack in FlowStone/Ruby?

[Tronic]

one trig from the Frame Sync is equivalent to the size of the current audio buffer
and the value that it output is the audio buffer size
so...

Code: Select all

for n in audio_buffer_size
# process x sample here
end

[Nowhk]

one trig from the Frame Sync is equivalent to the size of the current audio buffer
and the value that it output is the audio buffer size
so...

Code: Select all

for n in audio_buffer_size
# process x sample here
end

Yes, I know this (its also in the manual), but why it should help me for my task?

What I need to do is output MIDI at fixed time, not to manipulate audio (that can be done with your code). The only way I know for doing it in FlowStone is to use Ruby and time/scheduling (expressed in second, that can be retrieved by sample position where I need the event of course): output 0, midinote, t+myms

But Ive already did it: why your code (browse current frame samples) should help me in this and output MIDI "more" sync rather than what Ive already did and that cannot work?

Please, maybe I miss this point and I cant see it

[Nowhk]

i don't have this issue using it only as midi plugin triggering an external synth

I have the same problem also triggering external VST. Maybe that's a isolated 3.0.7 bug? Here the same as before, schematic plus exported vst:

Internal MIDI Sync VST MIDI Out.fsm

(610 Bytes) Downloaded 855 times

Internal MIDI Sync VST MIDI Out.zip

(1.76 MiB) Downloaded 868 times

If I load them in 2 channels and I follow any synth (one with reverse polarity) I can hear sound. Null test fails again.

[Tronic]

Get the Midi message accurately to the sample with flowstone for now it is impossible.
the maximum you can get is to have it generated almost precisely with a constant sequence,
with an error
1.1.00, 2.1.01, 3.1.02, 4.1.00,
I think it's a rounding problem for the primitive PPQ, and SamplePosition,
it is round them with a floor function?

Anyway, with my midi system queue in ruby, I get always a NULL test, ok, without any problem.

I repeat that,
if you want something working you would use:
PPQ or SamplePosition primitive,
convert it into a Frame for the ruby ​​with the primitive
Mono-to-Frame,
create a midi queue system,
processed per sample, the frame buffer of ppq or sample position
then, at precise offset you need, create a midi output

Remember to set, extremely necessary, the delay compesation, with its primitive.

This is the only system that seems to work quite well, but I repeat again, precise midi sample x sample is a dream.

I wonder why there is not a primitive,
such as Frame-to-Mono and Mono-to-Frame, but for the Midi?
Midi-Buffer to Midi
Midi to Midi-Buffer
processed x sample.

but it's dependent on how it is managed the midi in C++ side.

so, no more word on that.