Re: Setting server volume from doOnServerTree

Hi Mario, 

I also find the current handling of volume less than ideal, 
and have a more robust issue/proposal with testable implementation: 

https://github.com/supercollider/supercollider/issues/4157

Given the current rising interest in connecting SC systems by internet,
this would make a lot of sense to do now, as it makes server volume 
reachable for all connected users on that server. 

The concept is to make a permanent group with a fixed ID for server volume, 
and a permanent synth object that sends it new and free messages when needed.

This is much simpler than the current approach, and any remote client 
knows that group's nodeID is 2, and can thus get and set 
volume on that group reliably and predictably. 
(Not in there yet, but remote server objects can then also poll that volume level, 
and sync their local volume values to it for smooth changes and for displays.) 

Would that solve your question too?

I can turn this issue into a PR rather quickly 
- was just waiting for comments on it.

best adc


> On 31/05/2020, at 09:13 , [email protected] wrote:
> 
> 
> Hi.
> 
> I accidentally stumbled over a "race" condition.
> Calling s.volume.volume_ from doOnServerTree (if the method is
> run before updateFunc from Volume.sendSynthDef) will result in "stacked"
> attenuation.
> 
> Since the server is already running, volume_ will eventually create
> an ampSynth.  Later Volumes own ServerTree function (updateFunc) is
> run, which unconditionally sets ampSynth to nil and runs updateSynth.
> updateSynth in turn will check if ampSynth is nil, and create a new
> synth.  Now we have two ampSynths on the server and we can only control
> the volume of one of these.
> 
> I am wondering why updateFunc sets ampSynth to nil unconditionally.
> As far as I can see, just removing that line would fix this, since
> updateSynth will call set on ampSynth if it already exists.
> 
> Anyone familiar with that code could shed light on why this rather harsh
> ampSynth = nil
> is there?

> --
> CYa,
>  ⡍⠁⠗⠊⠕
> 
> _______________________________________________
> 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/