Am Sonntag, den 24. Februar 2002 um 11:35:28 Uhr (+0100) schrieb Thomas Grill:

...

is there something like pyrite for pd? i never used pyrite, but i love supercollider. some things are so much simpler to program in supercollider. on the other hand i like the click and drag way in pd, but sometimes it gets very complicated and cluttered.

I don't know pyrite (and the only thing my quick and dirty web search brought up deals with Palm handhelds), but I'm completely with you what concerns the lack of versatile scripting capabilities.

Pyrite was written by James Mc Cartney, the author of Super Collider for the 68K version of Max for the Macintosh in the early 90s (the Max without DSP) before he started the work on Super Collider. It was a very neat object as it was some sort of embedded programming language in Max. You double clicked the object box to open an editor window. The language he invented was somewhere between c, lisp and smalltalk and part of it have made it into Super Collider. It provided methods for creating inlets and outlets, timing and so on. After some years of heavy frustration to code simple programming constructs by the means of patch cables and objects boxes it was very refreshing to be able to write loops or to assign variables in a fraction of time and to have better overview about what you're doing. Although I really like the concept behind Max and PD, it was a very useful addendum, each having it strengths, where the other had its weaknesses. I ended up using pyrite to code about everything which was needed in a piece and just connect sliders, midi-io and numberboxes to the in and outlets. But alas, also this "language" had its limitations (lists being allowed only with up to 256 elements for example) and I ended up using lisp altogether for composing.

The ideal solution would be embeddable script boxes that can use pd objects as classes, their methods as methods and their inputs/outputs as variables. Of course some existing, widespread, mature scripting language should be used, possibly python or perl. To all the experts out there: is it possible to define abstract data types in these languages and implement all their methods in C/C++ code modules?

That would indeed be very cool, although I think part of this is already possible, since it is quite easy to write externals in C (and could be made even easier with some utility functions to facilitate i/o processing, type checking and so on) which can readily instantiate and use any known pd class and foreign processes can also be integrated quite easily (at least with linux). The only thing, I miss regularly is the possibility to exchange values between processes easily, accessing data strucures in both directions and so on. Maybe we could also think about a way, how to set up common data structures for pd and external processes.

Orm

Am Montag, den 25. Februar 2002 um 08:52:38 Uhr (-0500) schrieb Larry Troxler:

On Sun, 24 Feb 2002, Orm Finnendahl wrote:

...

Pyrite was written by James Mc Cartney, the author of Super Collider for the 68K version of Max for the Macintosh in the early 90s (the Max without DSP) before he started the work on Super Collider. It was a very neat object as it was some sort of embedded programming language in Max. You double clicked the object box to open an editor window. The language he invented was somewhere between c, lisp and smalltalk and part of it have made it into Super Collider. It provided methods for creating inlets and outlets, timing and so on.

<snip>

You might take a look a pd-scheme

http://www.westnet.com/~lt/pd

Larry

Hi Larry,

thanks for the tip. I think that's exactly what I was looking for and I will just go ahead and give it a try. I couldn't find siod on the link you provided, though. It took me a while to find a link which isn't broken as it seems to be quite an ancient implementation, but finally found one here:

ftp://ftp.cs.indiana.edu/pub/scheme-repository/imp/siod-3.2.tar.gz

Is that the version, you're using (its seems top be from 1996)?

Yours, Orm

Hi Larry,

your pd-scheme external is marvellous! Anybody interested in the possibility of scripting in the framework of pd should check it out. As I suggested in another private email I could imagine it would be nice to add some "plugs" to and from pd via fifos in order to access scheme directly from e.g. emacs in order to set values and check its behaviour interactively (for debugging purposes and such), but the reload function and the "()?" operator (IMO a very clever idea) make similar things somewhat possible.

I think I found some minor bugs in scm.c and pdinit.scm and will send the patches to you in a seperate mail.

Yours, Orm

just thought it's about time that i mention again that as far as i can tell, my nqpoly~ abstraction does at least what rabin~ is trying to do... only it does it using a self-constructing abstraction rather than as an external. still, it gets pretty good performance.

it is also only single channel.. duplicating an object across multiple channels is really a completely different dimension to work in. it could theoretically be done in the same way that i made nqpoly.. and then perhaps you could wrap an nqpoly instance in this new object to get a polyphonic multichannel abstraction to build itself automatically.. ouch... :)

anyhow maybe if it's so eagerly awaited you might like to look at http://pix.test.at/pd/nqpoly/ ... the documentation is pretty crap. but as a single redeeming feature, i answer emails.

pix.

On Mon, 25 Feb 2002 11:11:52 +0100 Krzysztof Czaja czaja@chopin.edu.pl wrote:

hi Thomas and all,

I have put the poly~ project aside, not even realizing it is eagerly awaited. Several ``balloon probes'' I have been sending to this list failed to uncover that...

After all, it is Miller who has the final say here. He can do this better than me. He can look into Pd's future. The poor rabin~ is just made to suit my current very simple needs, _and_ in the hope it could help (or provoke) designing of the proper thing.

Same goes for a score follower -- the xeq_follow is a crap, it is not a universal tool, but it is just what I need to have now.

Krzyszt-still-before-coffee-of

Btw. poly~ does not scale to multi-channel, all its voices are mixed.

Thomas Grill wrote: ...

...

...

also i'm missing some abstractions. in supercollider it's no problem to scale a patch from 1 to 4 to 16 channels. how could i make a patch with 48 channels, without drawing lots of lines? maybe it's possible and i just don't know it.

That will be possible once Krzysztof has finished his eagerly awaited poly implementation. See Max/MSP for reference.

hi,

I have just tried embedding grain~.pd abstraction (the one used in nqpoly~-test.pd) in rabin~. Maximum number of non-crackling voices in nqpoly~-test.pd on my 800Mhz box is 90. In rabin~ it went down to 75. The reason why rabin~ is slower is my checking for under- and overflows in each of the voices before adding to the mixdown. The reason why nqpoly~ does not have this penalty is that if there are several signals input into one inlet, they are all summed without checking (vide plus_perf8()).

Without these checks rabin~'s performance is exactly equal to nqpoly~'s. Further speedup is probably impossible.

The question is: are the checks necessary in this context?

Krzysztof

pix wrote: ...

tell, my nqpoly~ abstraction does at least what rabin~ is trying to do... only it does it using a self-constructing abstraction rather than as an external. still, it gets pretty good performance.

Miller wrote:

Hmm, I can't see very far into the future at all... but I'm probably going to have to spend most of my time dealing with integration&documentation

over

the next few months,

I was thinking about if there was a way to write a documentation as a co-production of several people (or maybe a tutorial) ... first published on the web and then maybe also in printable form. marius.