Hallo,
e skogen hat gesagt: // e skogen wrote:
I do have some suggestions. Well, actually only one: The loop parts of gyre would make a fine self contained Graph on Parent patch. This way, extending it to use more or less than the six loops in your patch would be much easier. I'd figure a patch "gyre.pd" that could be called as an abstraction like for example: [gyre loopname] or [gyre-gop loopname]
Like in the attached example gyre-gop, that would need some work at localizing it with $0-vars and inlet/outlets.
yes, that makes it a lot easier to work with. i only decided to avoid GOPs because they slow my system and because i wanted to keep the code and GUI seperate.
Well, GUI and code still *are* seperate when using looper and loader as in the example GOP. Maybe even more seperate than now. I agree, that GOPs can be slower, for example if you use a vu meter in them. But the added flexibility and ease of (re)use for other users is worth it, IMO.
Actually I'm searching for more generally (re)usable GOP abstractions for a talk I'm planning for the next linux-audio-dev conference in spring 2004. The talk will be called "RRAD-ical Pd - Reusable and Rapid Audio Development in Pd" and focuses on GOP abstractions. I anybody's interested I could send a short abstract.
David McCallum is doing great things in this area, I did several "RRAD" patches but in general there aren't that many useful and reusable GOPs available.
Frank Barknecht _ ______footils.org__