[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sc-users] Re: will there ever be real multiprocessor support?



And I think I understand it now - yes - this does make some sense...

I think I may have an idea about how to do this even. I'll take a look at scsynth later today and see if my hunch is correct. My guess is, somewhere the audio thread is added... I wonder if the answer may be an OSC message to create a second audio thread on the same server, and if this is possible? The 'second thread' would be the second group node that James is talking about. Shares memory and busses with the first one, but the two thread's synths can't reliably feed into each other?

Not even sure of this is how it all works. I'll try to take a look later.

Josh

On Mar 6, 2009, at 6:15 AM, Dan Stowell wrote:

I had missed this suggestion. It's a very interesting suggestion,
essentially it would be the same approach as Max currently uses,
allowing the user to explicitly define a parallelisable subgraph.
Would one be able to add serial-groups inside a parallel-group? Hope
so.

I'm trying to remember the parallellisation APIs I read a while back.
I think they would make this possible - no technical objections spring
to mind yet...

(btw it could probably simply be a new property of a group - default
serial but can flag as parallel - which would mean very little change
to scsynth's osc interface)

Dan


2009/3/6 James Harkins <jamshark70@xxxxxxxxx>:
Is there a technical objection to my suggestion of a second group node type,
that allows parallelism within it?
It seems to me this is a fairly simple and elegant idea that just might do exactly what we need: tell the server that this bunch of nodes must follow
this other node, and precede the next node, but within it, it's a
free-for-all.
The group node that we have now would be a "serial group," and the new type would allow parallelism among its immediate children. So if you wanted to distribute several source --> effect chains among different threads, you would have a "parallel group" containing a number of "serial groups." Within the serial groups, order of execution is guaranteed, but each of these serial groups contained within the parallel group could run independently on
a separate processor.
This is loosely inspired by Faust's parallelism operator, adapted to sc's node structure. There could easily be a technical reason why this would simply not work, but in the absence of that reason, it seems to me this is a reasonably small conceptual leap for end-users and it would also involve the least surgery. (I would say, whatever the final user interface is, it has to
be simple. SC is confusing enough as it is!)
hjh

--
http://www.mcld.co.uk

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-users/
search: https://listarc.bham.ac.uk/lists/sc-users/search/

******************************************
/* Joshua D. Parmenter
http://www.realizedsound.net/josh/

“Every composer – at all times and in all cases – gives his own interpretation of how modern society is structured: whether actively or passively, consciously or unconsciously, he makes choices in this regard. He may be conservative or he may subject himself to continual renewal; or he may strive for a revolutionary, historical or social palingenesis." - Luigi Nono
*/


_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-users/
search: https://listarc.bham.ac.uk/lists/sc-users/search/