Re: Setting server volume from doOnServerTree

adcxyz-A2/[email protected] writes:

> 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

Ahh, I see you already mentioned in 2018 the problem I described in this
thread.  So it is a known issue.

> 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 guess so.  If ampSynth gets its own permanent ID, I guess that would
also ensure that it can't be accidentally instantiated multiple times.

One thing I am slightly worried about is compatibility with older
scsynths.  At least in my setup, I am stuck with a 3.10.0 scsynth
running as a second server on a bela board.  I don't use server volume on
that server, but I wonder how the newer sclang would deal with initTree
on an older scsynth?

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

If a rewrite of Volume is pending, I'll just wait for that to land.

If no, I believe I know the fix for the resource leak currently exposed
by ServerTree objects setting volume.

> 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/

-- 
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/