The focus of Pd-Dom is very different though, it does dynamically "chain" abstractions that send and receive audio. It handles also loadbang to the freshly created instances. This should all be error free and within 0 latency (using subpatches).
Hi Enrique, Pd-Dom works looks great, thanks for sharing it. Just a question (I know i should simply try it myself, but I don't have the time atm, apologies)... Can Pd-Dom manage GOP abstractions with different dimension than a non-GOP object? I'm curious 'cause I'm actually working on something really similar to Pd-Dom but with a slightly different approach. I'm trying to use dynamic patching to easily build GUI chains with whatever GOP abstraction. I use unofficial dyn-patching methods too, and iemguts. although I still have to fix few bugs the method works pretty fine so far. So now I wonder whether implement your Pd-Dom.. thanks,
On 13/03/2010 11:15, Marco Donnarumma wrote:
The focus of Pd-Dom is very different though, it does dynamically "chain" abstractions that send and receive audio. It handles also loadbang to the freshly created instances. This should all be error free and within 0 latency (using subpatches).
Hi Enrique, Pd-Dom works looks great, thanks for sharing it. Just a question (I know i should simply try it myself, but I don't have the time atm, apologies)... Can Pd-Dom manage GOP abstractions with different dimension than a non-GOP object? I'm curious 'cause I'm actually working on something really similar to Pd-Dom but with a slightly different approach. I'm trying to use dynamic patching to easily build GUI chains with whatever GOP abstraction. I use unofficial dyn-patching methods too, and iemguts. although I still have to fix few bugs the method works pretty fine so far. So now I wonder whether implement your Pd-Dom.. thanks,
Hi Marco
As I mentioned before:
Pd-Dom itself has actually nothing to do with GUI.
:)
All the created abstractions are hidden in subpatches for signal-flow reasons, so they can't be GOP.
There is one, in "examples/04.gui2.pd" that does create a GUI. The created abstraction adds 2 sliders to a GOP in the main patch. Each instance sets the y position by knowing it's own position in the chain.
If they would have variable height this wouldn't work, instead I'd try to keep track of the height and y position with a [value] object.
Deleting one instance would have to redraw the whole GOP, which is a bit ugly but would work.
Did you manage to delete in your aproach?
Cheers eni
As I mentioned before:
Pd-Dom itself has actually nothing to do with GUI.
:)
oops, sorry.. read too fast.
[snip]
If they would have variable height this wouldn't work, instead I'd try to keep track of the height and y position with a [value] object.
Deleting one instance would have to redraw the whole GOP, which is a bit ugly but would work.
Did you manage to delete in your aproach?
I see, thanks a lot for the explanation. Yes so far I managed to build GOP audio chains with messages, give a specific ID, loadbang every abstraction, select with a click an abstraction (in running mode and avoiding multiple selection) and delete it. Then the chain is recomposed and all the other abstractions move back to not leave the empty space of the previously deleted one (kind of Ableton-boooo effects rack).
On ubuntu with Pd-ext 42.5 GOP redrawing works like a charm. Now I have 2 main problems I'm trying to solve: 1_ I want to be able to insert a new abstraction in a random position into the chain (i.e. not only in the end) 2_I want to be able to use whatever abstraction, with different dimensions (although it won't be that good for a usable appealing interface, but I prefer to do it in order to allow other people to easily use their abstractions)
That's why I started using iemguts (so glad it has been included in Pd-ext). I don't think it's going to be too difficult since I'll have to use the same methods with light modifications, but what I actually miss is a clean way to incapsulate this methods in high-level abstractions, as you have cleverly done.
cheers,