[PD-dev] PD as a plugin (VST,LADSPA,jack)

[=?X-UNKNOWN?Q?g=FCnter_geiger?=]

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