> ~ambiServer = { arg i; Server.embed(Synth("ambi", [\out, ~ambiBus[i]]), addr:
> ~myAddr[i], ~myOptions, synth: Synth("test")); } ! 4;
d'oh. this should read:
~ambiServer = { arg i; Server.embed(Synth("ambi", [\out, ~ambiBus[i]]), addr:
~myAddr[i], ~myOptions); } ! 4;
---
and I just want to add that this is really orthogonal to the Supernova
approach, it's actually possible to have both.
Christof
> Gesendet: Dienstag, 28. Mai 2019 um 12:09 Uhr
> Von: "Christof Ressi" <[email protected]>
> An: [email protected]
> Betreff: Aw: Re: [sc-dev] Re: [sc-dev] sc-dev meeting minutes
>
> > Where it is unfortunate (now) is that, for each server that needs to access
> > memory, each server needs to allocate it’s own.
>
> yes, embedding Servers doesn't solve this problem either but often we have
> more than enough RAM anyway.
>
>
> > Physical Output buses, obviously, get summed together for you when writing
> > to the sound card, but this is different than what happens if two instances
> > of scsynth write to then same virtual bus, and I think is something that
> > will lead to confusion with this approach. Not that it can’t be overcome,
> > but I do think it is an issue. Especially in case where you are writing
> > sound to many buses that need additional processing done (for example,
> > writing output with Amibisonic encoding that needs to be decoded for each
> > instance of scsynth).
>
>
> that's exactly where embedded Servers can help. here's a fictional example:
>
> (
> // SynthDef to produce a 3rd order ambisonic signal in a seperate Server
> instance
> SynthDef("ambi", { arg out;
> Out.ar(out, Server.ar(numOut: 16));
> }).add;
>
> // create 4 ambisonic busses
> ~ambiBus = { Bus.audio(numChannels: 16) } ! 4;
>
> // create 4 NetAddress
> ~ambiAddr = { arg i; NetAddr.new("localhost", 57111 + i) } ! 4;
>
> // create some Server options if needed
> (numInputBusChannels/numOutputBusChannels can be deduced from the Ugen)
> // ~myOptions =
> )
>
> // create 4 Servers with the fictional "embed" method: Synth, name, addr,
> options, clientID
> // internally, each Server instance writes to its 16 hardware outputs and the
> Ugen will route this to the given audio bus (= ~ambiBus[i])
>
> ~ambiServer = { arg i; Server.embed(Synth("ambi", [\out, ~ambiBus[i]]), addr:
> ~myAddr[i], ~myOptions, synth: Synth("test")); } ! 4;
>
> // now we can encode each ~ambiBus signal and finally decode all of them.
>
> ---
>
> does this make sense? we actually do stuff like this in Pd with [pd~].
>
> the key point is to realize that Server.ar really is a Unit generator (a
> block box which consumes/produces audio). Internally, the Ugen would probably
> buffer the inputs and outputs, so we wouldn't need to implement any audio bus
> locking. the procedure is:
> a) lock the buffer
> b) copy Ugen input to buffer, copy last Server result to Ugen output.
> c) unlock and signal the embedded Server to process the next block
> we would get a constant delay of one block but we should never have to wait
> for the embedded Server.
>
> treating a Server like a UGen means we can freely (and dynamically!)
> interconnect different Server instances in Supercollider and also nest them
> arbitrarily. Running each Server on its own thread is a very simple solution
> which doesn't scale (having too many threads can lead to performance issues),
> but for many use cases it would be fine I guess.
>
> I can probably hack together a prototype of this in a day or so, maybe I do
> this in summer :-) Of course, the Supernova approach is vastly superior but
> also though to implement.
>
> Christof
>
>
> > Gesendet: Dienstag, 28. Mai 2019 um 04:53 Uhr
> > Von: [email protected]
> > An: [email protected]
> > Betreff: Re: [sc-dev] Re: [sc-dev] sc-dev meeting minutes
> >
> >
> >
> > > On May 27, 2019, at 7:47 PM, [email protected] wrote:
> > >
> > > I've written a multithreaded virtual modular synthesizer and it is quite
> > > easy as long as the thread management is done manually (the user says:
> > > please run this node on thread X) but it gets hairy when it should be
> > > done automatically (e.g. based on average CPU use).
> > >
> > > ---
> > >
> > > but there's also a totally different possibility of concurrency:
> > > embedding Scsynth instances within itself. In Pd there's an object [pd~]
> > > which runs a seperate Pd instance in another process. You can
> > > send/receive audio and messages, but you can't immediately share data
> > > (although there's the "shmem" external for shared memory). The reason Pd
> > > has to run in a seperate process is that it is a fundamentally
> > > single-threaded program with lots of global state (but there have been
> > > recent efforts to overcome this limitation utilizing thread local
> > > storage).
> > >
> > > AFAICT, Scsynth on the other hand has very little (mutable) global state:
> > > gUnitDefLib, gBufGenLib, gPlugInCmds and those dictionaries can actually
> > > be shared across instances (they just have to be made thread-safe). This
> > > means it would be possible to run a complete seperate Scsynth instance
> > > inside a single Ugen in a dedicated thread. The parent and child
> > > instance(s) don't share any data, but they can exchange audio data (and
> > > maybe also control data). You can basically achieve the same thing with
> > > running several Scsynth processes and connecting them with Jack, but
> > > doing it all in Supercollider makes the routing much easier and you can
> > > exchange audio with guaranteed minimal latency.
> > >
> > > the only thing it takes is writing a fake audio driver and export a
> > > function with which you can tick the driver, similar to the callback
> > > functions of the real audio backends. the UGen would just need to call
> > > this function in the perform routine; actual Server creation (+ options)
> > > could be handled asynchronously with unit commands (like VSTPlugin). it
> > > could look like this:
> > >
> > > // SynthDef to process a stereo audio signal with a seperate Server
> > > instance
> > > (
> > > SynthDef("test", { arg in, out;
> > > Out.ar(out, Server.ar(in: In.ar(in, 2), numOut: 2));
> > > }).add;
> > > )
> > >
> > > // open Server inside a Synth node
> > > ~myServer = Server.new("foo", ~myAddr, ~myOptions, synth: Synth("test"));
> > >
> > >
> > > would someone find this useful or is this just ridiculous? :-D
> >
> > How would this address the issue of shared memory / busses between
> > instances that are controlled by the dummy server?
> >
> > Personally, I already manage different instances of scsynth that don’t need
> > input / output from other instances to take advantage of multiple cores.
> > Where it is unfortunate (now) is that, for each server that needs to access
> > memory, each server needs to allocate it’s own.
> >
> > Physical Output buses, obviously, get summed together for you when writing
> > to the sound card, but this is different than what happens if two instances
> > of scsynth write to then same virtual bus, and I think is something that
> > will lead to confusion with this approach. Not that it can’t be overcome,
> > but I do think it is an issue. Especially in case where you are writing
> > sound to many buses that need additional processing done (for example,
> > writing output with Amibisonic encoding that needs to be decoded for each
> > instance of scsynth).
> >
> > Best,
> >
> > Josh
> >
> > >
> > > also, with the exported tick function it wouldn't be too hard to also
> > > embed Supercollider in a VST plugin or Pd external.
> > >
> > > Christof
> > >
> > >> Gesendet: Dienstag, 28. Mai 2019 um 02:07 Uhr
> > >> Von: [email protected]
> > >> An: sc-dev <[email protected]>
> > >> Betreff: Re: [sc-dev] Re: [sc-dev] sc-dev meeting minutes
> > >>
> > >> On Tue, May 28, 2019 at 6:37 AM <[email protected]> wrote:
> > >>> I see a few routes for the _hypothetical_ unification:
> > >>> - There's the route of putting code from scsynth "into" supernova
> > >>> - The reverse (supernova code "into" scsynth)
> > >>> - Reimplement ParGroups in scsynth without using supernova code at all
> > >>
> > >> My opinion is that this -- reimplementing -- is probably the best way.
> > >> See below.
> > >>
> > >>> - Just start using supernova for everything, and fix as many bugs as
> > >>> needed for everyone to be happy with that route
> > >>
> > >> The major bug here is -- I recall reading in Tim's master's thesis
> > >> that supernova builds a dependency graph internally for thread
> > >> allocation. The dependency graph must be updated when groups (parallel
> > >> or not) are moved.
> > >>
> > >> It happens that I sometimes issue a lot of group-moving commands in
> > >> quick succession (MixerChannel automatically reorders groups according
> > >> to channel output and pre-/post-send routing). I've seen in a number
> > >> of cases where creating and deleting a large number of mixer channels
> > >> (e.g., a section transition in performance) causes supernova to crash.
> > >>
> > >> I believe there is some stress condition that causes supernova's
> > >> dependency graph calculation to break.
> > >>
> > >> If this is not fixed, then reusing supernova code is IMO a non-starter.
> > >>
> > >> So far, the dev community has treated this part of supernova as a
> > >> black box. We'll have to open it up and fix it (and it's difficult to
> > >> reproduce -- I could crash it 80% of the time with a large, complex
> > >> live set, but I've failed to create a smaller reproducer), or create a
> > >> new implementation that simply doesn't use this code.
> > >>
> > >> hjh
> > >>
> > >> _______________________________________________
> > >> sc-dev mailing list
> > >>
> > >> info (subscription, etc.):
> > >> http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
> > >> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
> > >> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
> > >>
> > >
> > > _______________________________________________
> > > sc-dev mailing list
> > >
> > > info (subscription, etc.):
> > > http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
> > > archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
> > > search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
> >
> >
> > _______________________________________________
> > sc-dev mailing list
> >
> > info (subscription, etc.):
> > http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
> > archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
> > search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
> >
_______________________________________________
Pd-dev mailing list
[email protected]
https://lists.puredata.info/listinfo/pd-dev
