Sorry, I wrote this before I received the digest with the answers.

Thanks for the replies.

[pd~] is still coming quite in handy. I'm now allowed to open 2 instances of my abstractions that take almost 90% CPU each. Works perfectly!

Too bad it can't unsync the clocks. It's very "elegant", to just open one file, and have it all there.

I know about the paper and figured it couldn't be done and all... I'm not that well versed in programming to go deep under the hood and give you objective possibilities or ways around. But I still have some ideas that seems to be reasonable. Like, there could be a new [pd~] like object, that would allow this to be possible to this exact kind of purpose.

Because when I see another "Pd" opened so I can use the net objects, it just look the same as if I had opened it with [pd~] subprocesses. I assume there's a way to do it.

But you could still have this new function inside [pd~]. Then, with some sort of flag or creation argument, [pd~] could function like that.

Anyway, I'm sure there can be quite a hassle, and maybe just "not worth it", but I don't see it as something impossible. Do I have a point?

Thanks
Alex



2011/12/1 Alexandre Torres Porres <porres@gmail.com>

well, for the record, I tried and [netsend / netreceive] are doing the trick.
cheers


2011/12/1 Alexandre Torres Porres <porres@gmail.com>
Hi folks.

Now that pd~ works well for me. I'm sad to see it is not doing what I hope it would. Maybe I could send the patch, but it's simple so I think there's no need.

What it does is that it takes a snapshot of the spectrum and does pretty extensive calculations with it, gets combinations of the lists' elements, does transpositions, plots a graph over 1200 points, bla bla bla.

When I do it on my patch, Pd just freezes completely, the audio stops, and it then waits until all of this is over to come back to life. It usually takes around 10 seconds!!!

I thought that if I put all of this in a separate patch under [pd~] that it would do all it had to do without killing the audio in the parent/super patch. But Nothing Changes!

I figure it must be related to the "attention" in the help files, which says something like: "subprocess' clock is slaved to audio I/O it gets from superpatch!".

In other words, the clocks are in sinc. So if one stops, the other waits. 

is that it???

If so... no way around to change this with [pd~], right? 

But would it be possible to review this and maybe allow it for future versions?


So then, how is it possible to have a separate process, in a separate core, with an independent clock?

- Use separate computers? - Just open another actual Pd and send messages to it via net objects? 

Thanks a lot.
alex