Hallo, Marco Scoffier hat gesagt: // Marco Scoffier wrote:

On Mon, Jan 27, 2003 at 05:07:09PM +0100, Frank Barknecht wrote:

...

and Pd itself with

% cvs -z3 -d:pserver:anonymous@cvs.pure-data.sourceforge.net:/cvsroot/pure-data co pure-data

To check out the current developers' branch, which is tagged with devel_0_36, use

% cvs -z3 -d:pserver:anonymous@cvs.pure-data.sourceforge.net:/cvsroot/pure-data co pure-data -r devel_0_36

Thank you for this information, I have been looking for this. But it is slightly wrong pd not pure-data % cvs -z3 -d:pserver:anonymous@cvs.pure-data.sourceforge.net:/cvsroot/pure-data co pd

Argh, you're absolutely right. My mind was playing tricks on my, sorry.

ciao

Frank Barknecht _ ______footils.org__

On Mon, 27 Jan 2003, Frank Barknecht wrote:

To check out the current developers' branch, which is tagged with devel_0_36, use

% cvs -z3 -d:pserver:anonymous@cvs.pure-data.sourceforge.net:/cvsroot/pure-data co pure-data -r devel_0_36

You can see the available branches in the pulldown menu on http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pure-data/pd/ (or use "cvs -T ...")

Thank you very much. I was not able to find out this by man cvs.

...

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 don't know which patch is in devel_0_36, I don't use jack currently, but the source should show it.

Problem with that one is that its not callback based. :(

...

Is there such an external allready by the way?

I don't think it is, but actually I wouldn't put too much work into it, because IIR Miller is redesigning the audio out/in system to a more plugin oriented architecture. But only Miller could tell more about this.

Okey, thanks.

Hallo, Kjetil S. Matheussen hat gesagt: // Kjetil S. Matheussen wrote:

kjetism@olivier ~/pd/dev_36 $ cvs -z3 -d:pserver:anonymous@cvs.pure-data.sourceforge.net:/cvsroot/pure-data co pd -r devel_0_36 cvs server: cannot find module -r' - ignored cvs server: cannot find moduledevel_0_36' - ignored cvs [checkout aborted]: cannot expand modules kjetism@olivier ~/pd/dev_36 $

Okay, I messed up big time, but the solution is simply a wrong ordering of arguments. This one really should work now, I even tested it:

% cvs -z3 -d:pserver:anonymous@cvs.pure-data.sourceforge.net:/cvsroot/pure-data co -r devel_0_36 pd

If one, like me, has done this once, he's only doing "cvs update" afterwards...

ciao

Frank Barknecht _ ______footils.org__

Anyone get:

cvs [update aborted]: cannot open flatom.cpp: Permission denied

when trying to 'cvs update'?

d

david casal --0+

d.casal@uea.ac.uk --9+

ecdc.dyndns.org/dc --)+

On Tue, 28 Jan 2003, david casal wrote:

hey again:

in build/README.txt, it says just to cd to your platform dir and type make...for darwin, this gives:

make: *** No rule to make target 'choice.pd_linux', needed by 'pd_linux'. Stop.

Is this really meant to be a 'build all externals in the cvs tree' makefile? do I just change the target (and to what) ?

Its meant to be a build all externals except some (zexy,osc,flext). Then I think, this really only works on linux. (unless we have an anonymous contributor that updated the build system without my knowledge). It would be great if someone could contribute build support for darwin and windows.

solved the permission problem ?

Greetings,

Guenter

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

On Tue, 28 Jan 2003, Frank Barknecht wrote:

...

I think so. At least I want to run freqtweak as a pd oject.

That would be way cool.

Well, now you do have k_jackd~ :)

gg:

...

...

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?

Just some quick thoughts: Threading GUI and audio,

This one should be easy, and is more or less required for a callback based jackified pd to work properly.

making another GUI toolkit possible,

To much work.

a cleaner self-generation of patches, poly~, ...

Dont consider that important. Better to write your own externals.

On Tue, 28 Jan 2003, Thomas Grill wrote:

It's important if one wants to move away from the visual top-in bottom-out style. For many applications flexible polyphonic sound production is necessary and vital. I suggest to have a look at the SuperCollider language which has the ability to create massively parallel patches, with fully dynamical voice allocation - this is really impressing, but otoh the scripts can be quite hard to comprehend.

One major feature missing from PD/jMax is special objectboxes that have subpatchers as arguments. This would give PD/jMax more of the flexibility that other dataflow environments such as LabView has.

(Note: I haven't tried LabView yet).

Then it would be easy to specify massive and/or variable-width parallelism.

If there is no such feature, then the way out is using lists and vector-values and create a lot of new classes that behave like the existing ones except that they operate like N objects of the same class at once. This would not require changing PD/jMax itself. It would be a lot of effort to make all classes work this way, and it's not really doable, and there are things that are more difficult to do with this approach than the ones above. However there are also advantages (speed).

The PD/jMax external closest to that latter ideal is, of course, GridFlow. But it's not like GridFlow can even get close to that ideal because there are way too many classes/externals to rewrite, and it does not handle DSP at all, etc.

So it gets me back to the subpatcher-as-argument. Let's see what would be required to get there.

jMax already has subpatchers; you double-click on it and a separate window opens; however the subpatcher is stored in the same file as the patcher. PD could get this feature.

(the advantage of jMax stops here.)

Then it would be good for abstractions to be embeddable in the same file as a main patcher. The difference between a subpatcher and an abstraction is that an abstraction may have several instances of itself inside the same patcher. The advantage of embedding abstractions is that it makes it more convenient (or less inconvenient) to build heavily structured patch-systems; you can put what would be 42 different .pd files inside only one, no need to give it a directory of its own, no use for zipping it to distribute it.

Then it would be good to allow visually-embedded subpatchers. Then allow non-text inside objectboxes (so that I can put matrix literals inside object boxes in a nice form; see game_of_life.pd to get an idea of how ugly matrix-literals may get). Then allow processing-objects inside objectboxes; this implies subpatchers (incl. the visually-embedded ones) are allowed inside objectboxes.

From there it would be nice to have an object that can vectorize GUI

objects so that I can get a matrix of checkboxes or a vector of sliders.

I actually often wish I had some kind of vector-of-sliders in jMax that would send out lists of integers. I have a use for that, as I often copypaste sliders and align them side-to-side and pack their outputs into vectors.

I would also wish the same for PD, but I don't really use PD, for several reasons. (if PD had some of the above features I could quickly consider it as superior to jMax)

That's why i'm developing dyn~ right now. It's a very simple approach to dynamically manage all kinds of pd objects invisibly inside an external. It can serve as a poly~ but also for other applications.

May you explain how dyn~ would work?

Mathieu Bouchard http://artengine.ca/matju

On Tue, 28 Jan 2003, Thomas Grill wrote:

...

The PD/jMax external closest to that latter ideal is, of course, GridFlow. But it's not like GridFlow can even get close to that ideal because there are way too many classes/externals to rewrite, and it does not handle DSP at all, etc.

I thought over it for quite some time and i've come to the conclusion that using standard pd message and dsp objects is the way to go.

Oh well. You see, the GridFlow way has its advantages. By making patches out of multidimensional array operators, an incredible amount of work can be done with very little message-passing, and the supporting library (GridFlow) can do some insane vectorizing of operations. For high-bandwidth numeric computing, you shouldn't have zillions of objects passing around zillions of messages... it would be over 100 times slower (I tried)

So it really depends on the case. I am conscious there isn't a single best way of doing things. The dyn~ object will have its niche too.

Mathieu Bouchard http://artengine.ca/matju

Hi Mathieu,

Am Dienstag, den 28. Januar 2003 um 14:54:21 Uhr (-0500) schrieb Mathieu Bouchard:

One major feature missing from PD/jMax is special objectboxes that have subpatchers as arguments. This would give PD/jMax more of the flexibility that other dataflow environments such as LabView has.

jMax already has subpatchers; you double-click on it and a separate window opens; however the subpatcher is stored in the same file as the patcher. PD could get this feature.

Sorry if I'm missing something, but could it be that you don't know of the "pd" object, which is the same as the "patcher object" in Max/MSP? It does everything you mention and is stored in the same file as the main patch.

(the advantage of jMax stops here.)

Then it would be good for abstractions to be embeddable in the same file as a main patcher. The difference between a subpatcher and an abstraction is that an abstraction may have several instances of itself inside the same patcher. The advantage of embedding abstractions is that it makes it more convenient (or less inconvenient) to build heavily structured patch-systems; you can put what would be 42 different .pd files inside only one, no need to give it a directory of its own, no use for zipping it to distribute it.

I don't see the difference between what you describe and what an abstraction is in pd (it is basically one file in the same directory as the main patch and the main patch stores references to the abstractions instead of the abstraction code to minimize file size).

Then it would be good to allow visually-embedded subpatchers. Then allow non-text inside objectboxes (so that I can put matrix literals inside object boxes in a nice form; see game_of_life.pd to get an idea of how ugly matrix-literals may get). Then allow processing-objects inside objectboxes; this implies subpatchers (incl. the visually-embedded ones) are allowed inside objectboxes.

Did you check the "graph on parent" feature?

...

From there it would be nice to have an object that can vectorize GUI

objects so that I can get a matrix of checkboxes or a vector of sliders.

I actually often wish I had some kind of vector-of-sliders in jMax that would send out lists of integers. I have a use for that, as I often copypaste sliders and align them side-to-side and pack their outputs into vectors.

I attach a patch which dynamically allocates a matrix of checkboxes. Just click on the different lists to get different row/column settings. The checkboxes send to and receive from distinct locations (check the properties dialog for values) and the patch includes the graph on parent feature to be somewhat clearer. You can do the same with any gui object (or basically any object of pd), including dynamical allocation of patch chord connections when needed. And the create-checkboxes subpatcher could be saved as an abstraction for reusability (e.g. specifying rows and columns as arguments). You could also add all sorts of bells and whistles like covering titles and unneeded object boxes with canvases, dynamically color the checkboxes/sliders etc.

Does that serve your needs or am I completely off topic?

-- Orm

Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:

Other things I find excessively annoying is the inability to wrap objectbox/commentbox text properly.

I like, how Max/MSP does it, it lets you resize everything with the mouse.

I said I'd like abstractions that are included inside .pd files as if they were subpatchers, but otherwise work like abstractions. It would encourage aggressive abstraction; otherwise it is tempting to copypaste subpatchers in order to keep everything in one file.

I'd disagree here. Subpatches and abstractions (in Pd) are fundamentally different. Abstractions are for, well, abstraction as a concept, with local variables, creation arguments and all that, but subpatches have two other goals. One is simply to hide things from view (or let only a GUI be visible via GOP), the other is creating named space inside a patch, that can be e.g. a target for self-modifying messages or struct data. As abstractions can include subpatches and as they pass on the graph-on-parent features, subpatch functionality is available there as well. So if one needs aggressive abstraction, and everyone needs that sooner or later, one should of course use abstractions for that and not subpatches. Having abstractions inside a patch is not aggressive abstraction but only leads to many copies of functionality, that then isn't abstracted (inside a patch file).

ciao

Frank Barknecht _ ______footils.org__

hi,

at least for comments, there is a mean substitute in the cyclone. You may write 'comment <width> <fontsize> <fontproperties> <text>'.

These are editable (and transformable into regular comments), no resizing with the mouse, though, and courier font used only (font properties field is ignored, currently), but any size is ok.

Such comments are really needed -- imported max patches are an unreadable mess without.

But well... having more then a few font sizes in a patch makes it horribly slow in loading -- maybe someone knows why?

Should I investigate, or is it a known tcl/tk (X Window?) problem?

Krzysztof

Frank Barknecht wrote:

Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:

...

Other things I find excessively annoying is the inability to wrap objectbox/commentbox text properly.

I like, how Max/MSP does it, it lets you resize everything with the mouse.

Hallo, Kjetil S. Matheussen hat gesagt: // Kjetil S. Matheussen wrote:

...

...

I think so. At least I want to run freqtweak as a pd oject.

That would be way cool.

Well, now you do have k_jackd~ :)

I didn't follow your recent developements: What's k_jackd~?

ciao

Frank Barknecht _ ______footils.org__

Kjetil S. Matheussen wrote:

...

I didn't follow your recent developements: What's k_jackd~?

A jackd and libjack replacement running inside pd. Horrible alpha, but works. www.notam02.no/arkiv/src

how stable is is k_jackd~? does it crash pd or are there some other problems?