[PD] Pd and jack (again)

[Kjetil S. Matheussen]

On Tue, 28 Jan 2003, guenter geiger wrote:

>
> On Mon, 27 Jan 2003, Kjetil S. Matheussen wrote:
> > Sorry if I have overlooked anything. But I have
> > browsed this mailing list and the development list,
> > and the jack mailing list, and various home-pages.
> >
> > And I am confused about what patch and which version
> > of pd to use if I want to jackify pd.
> >
> > I would prefer a callback based version, like the
> > jack_0_35_0_cb branch version in the pure-data cvs.
> > Is this one okey, or is there a newer one?
> >
> > And, big question, how do I download it without
> > taking each file manually? I dont know enough about
> > cvs.
>
> Knowing cvs is important for free software developers.
> Take the time and learn it, it will be very useful.
>
Sure, I've been using cvs a lot. But just basic
commit/checkout/add/remove/update. And I really did
use some time reading documentation about how to
handle branches before posting, but didn't find it out.


> >
> > The reason for wanting a callback based patch is
> > because I'm planning to make a general jack port
> > external.
> > And it wont work very good with a non-callback
> > based patch, I think.
>
> I do not understand why you need a jack enabled pd
> if you want to write a jack port external.
> What will the jack port external do, if not replacing
> the solution that exists now ?
>

A pd external with the syntax "jack~ <portname>".


> The problem with the callback based patch is that pd
> will run in the callback entirely, and pd by itself
> is not always Realtime capabable.

I know. I have read the source. But its not that much code.
The gui and midi things can be put into a different thread
that is synchronized with the jack thread (without blocking).


> That is why I
> decided to make the buffered jack I/O the default.
> With the callback based version you can kill the whole
> jack chain, with the buffered version you will just get
> a click when pd GUI load gets too high.
>
GUI code must of course be put in its own thread. I have
looked at these things as I said.

But the problem with non-callback based jack support
when having a jack~ external as described above, is
that the ringbuffer based jack thread is not at all
synchronized in any way with the pd dsp code.

When the pd dsp code is the same thread as the jack
thread, all input and output buffers are ready to use
when the jack~ objects are called, and no buffering
or (horrible solution) waiting has to be done inside
either the jack thread or the pd dsp thread.


> > Is there such an external allready by the way?
> >
>
> Not that I know of.
> Is there a need for it ?

I think so. At least I want to run freqtweak as a pd oject.
How can you do that now, besides using k_jackd~ ?


> I am not sure if I would recommend the development of such an
> external. There are so many more useful things to do, and
> we are in need of people who have the time to do that.
>
Whats more useful?

Anyway, an alternative (and very general) solution to a jack~ external
would be to make a jack->ladspa wrapper ladspa plugin, but
such a thing will introduce buffering and probably some
horrible hacking. Allthough it would be a _really fun_
thing to make. :)



--