Re: Setting server volume from doOnServerTree

> On 31/05/2020, at 13:20 , Mario Lang <[email protected]> wrote:
>
> [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.

that is a major point in my proposal.

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

setting up default group structure as in initTree happens in sclang,
and then creates just plain vanilla groups in scsynth from sclang.
the scsynth version cannot make any difference here.

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

I'll try to PR it soon :-)
best adc