DSP Robotics Support

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...

Tronic wrote: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

Nubeat7 wrote: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:



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

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.