Hi Miller, hi Stefan and dev-list,
Looking at the two jack implementations of pd at hand, I gave the whole topic another thought, and I think that pd needs a separate scheduler in order to serve as a plugin.
I am trying to outline why Stefans solution is much better than the FIFO solution, and actually, the good thing is that we should be able to use the same approach to make pd plugable as VST plugin.
1) Latency
The FIFO solution will always introduce one block of latency (as defined by the callback API, so this block will be larger than the 64 samples pd uses).
e.g. just to copy the input to output, the FIFO guards the input in the callback (be it jack, VST or anything else), and at the same time writes the result of the calculation from the last block.
Whereas the correct solution would be to get the input -> process it -> write the output.
There is a way around this by synchronizing via locks, though, but handling getting rid of locks and doing the processing in the loop directly seems to be a clearer solution.
2) A bigger problem is timing.
Currently pd implements its timing with 64 sample resolution, there is no way to calculate several of these blocks faster than realtime, because the sys_microsleep keeps the processing loop synced to real time.
This is good, because MIDI timing for example depends on this.
For a callback solution we cannot stay in realtime, we have to be faster in order to give other plugins a chance to do their processing, so the microsleep has to be thrown out.
This, in turn will destroy MIDI timing.
One thinkable solution to keep the timing correct is a new thread that buffers realtime events, it should buffer and timetag them, this way, of course latency for realtime events will be increased.
Note that this problem persist for both, the locked FIFO and the processing in the callback.
3) I do not fully understand why the "non realtime capable" operations such as patch loading, array loading, are worse than before when using Stefans implementation of the jack API. To me it seems that they should have exactly the same impact as they already have. Stefan, do you have an idea why this might not be the case ?
Sorry for the length of the message
Greetings
Guenter