DSP Robotics Support

Hi,

been a while since I posted here but I've still been working on my physical modelling drum synth and have started to look into the possibility of internal triggering as an alternative option to just attempting to filter plain incoming audio sources, allowing more reliable results across varying sources.

I have got a few tests made which are close to working reasonably well but I have a little worry about latency almost regardless of implementation. Presumably the 'single sample at a time' processing in Flowstone must receive a long buffer of samples from ASIO for example and then feed us one of these at a time at the sample rate. The trouble with this is the fact that a 512 buffer at 44100hz is 10ms which will be the delay in seeing the end sample. any buffers I then use in code to look back through for peaks will add to this.

basically what I want to do is have some of my code work more like a typical C++ plugin where you are free to manipulate each full buffer received from ASIO straight away. This could also be good for fft's as they could be calculated on the first sample of a new buffer.

Is there any way to do this in Flowstone or would I need to wait till I start porting stuff to C++?

It is not directly possible in FS, but ruby stream processing is frame based, so if nothing else, you can extract the buffersize form there and use latency compensation. If you are looking for real time performance, then FS is not the answer probably...

It did seem that way but best to check.

I was interested when I saw the ruby DLL thing but as you said i'm going for realtime. The idea is to have individual drums as mini vst effects each on their own mixer channel in a host and trigger internally from a sensor (e.g piezo) connected to any ADC. This would avoid the latency of external MIDI (I guess within a host there isn't any) and avoid the routing mess of having to use a trigger vst effect connected to an instrument or using external trigger software.

Ah well, guess this limitation might at least force me to minimize the latency in my methods making a later C++ version even better

You can configure the ASIO buffer size down to e.g. 64 samples. Just set it big enough to avoid clicks and dropouts for your application and setup.