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