hi all,
if anybody would like to look at what could be a simple way (option a) in my Saturday's post) to make a polyphonic instrument class, there is a prerelease (or better: a barely working prototype) of rabin~ external at suita.chopin.edu.pl/~czaja/miXed/externs/rabin.html
Coding this one had been very simple, thanks to the cleaner api of pd-0.35-test8. So simple, that I wonder if I have not missed any serious trouble spots. If not, and if Pd api does not change soon, then I will attempt the proper design (but again, no promises!). What this could be? Do we really need (numbered!) in/outs as in poly~, instead of regular inlets/outlets? Is thispoly~ the right mechanism to choose?
The rabin~ (this name is reserved only for the current restricted, remote controlled, and very rough prototype) will not work with earlier versions of Pd, and there is no .dll. The only example, rabin-test.pd, uses xeq library (to show how to connect the two), but works also without xeq installed, with just a [notein] as a source of notes.
Krzysztof
hi all,
ok, I have made all sorts of crashy trials, attempting to cheat
class mechanism of Pd, and the conclusion is that probably it is
impossible to handle ordinary inlet and outlet objects in an
abstraction embedded in an external, if the code was to stay clean
and reliable. On the other hand it looks like handling specialized
objects, like ins' andouts' in Max, should be possible. Now
I will put this project aside for some time, waiting for any
suggestions from the more knowledgeable...
Krzysztof
(hoping to be wrong)
Krzysztof Czaja wrote: ...
serious trouble spots. If not, and if Pd api does not change soon, then I will attempt the proper design (but again, no promises!). What this could be? Do we really need (numbered!) in/outs as in poly~, instead of regular inlets/outlets? Is thispoly~ the right mechanism to choose?
-
Krzysztof Czaja