Hi folks, I'm plonking away on the Max port of csound6~, and I see there are two ways of getting key/value settings in, invalue opcode controls through the "control" message and chnget opcodes through the "chnset" message. I've looked at the manual, but would like to know more about the difference between these two. If anyone could tell me more or point me at resources on why/when/for-what one would choose one over the other, that would be lovely!

iain

Backward compatibility would suggest that you support both. Please.  The invalue opcode was first and much of my early "csound for live" work uses invalue.   (Now, in Cabbage, my students and I are always using the newer chnset/chnget opcodes.)

Dr. Richard Boulanger

Professor

Electronic Production and Design

Berklee College of Music

On Dec 31, 2021, at 3:46 AM, Tarmo Johannes <trmjhnns@gmail.com> wrote:



Hi!

CsoundQt uses both options for communicating with UI widgets. invalue requires setting callback functions that deal with the channel values, chnget uses directly the Csound API. The latter is more efficient and easier to use, I suggest go with chnget/chnset unless you need more control over the values or want to support both for the user's sake.

chnget/chnset need in most cases that user declares the channels with chn_k (or similar) opcode in their csd

Greetings,

tarmo

Kontakt Iain Duncan (<iainduncanlists@gmail.com>) kirjutas kuupäeval R, 31. detsember 2021 kell 04:34:

Hi folks, I'm plonking away on the Max port of csound6~, and I see there are two ways of getting key/value settings in, invalue opcode controls through the "control" message and chnget opcodes through the "chnset" message. I've looked at the manual, but would like to know more about the difference between these two. If anyone could tell me more or point me at resources on why/when/for-what one would choose one over the other, that would be lovely!

iain

They both exist because we did not have a good curation system for contributions back then.

Someone contributed invalue/outvalue. Then Istvan Varga ignored it and wrote the named channel bus system alongside it.

So we ended up with this duplication. We have to keep both systems because of backward compatibility. For 7 we should think of a way in which invalue/outvalue are just aliases of chnget/chnset.

Prof. Victor Lazzarini

Maynooth University

Ireland

On 31 Dec 2021, at 16:35, Iain Duncan <iainduncanlists@gmail.com> wrote:



*Warning*

This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.

Thanks folks. I'm porting both, and I understand the API differences (from Victor's code for csound6~ for Pd). My question was more the practical differences so that I can explain why they both exist in the help file. For example, Tarmo said "unless you need more control". Is there a practical difference to the *user*, aside from the fact that one doesn't need to predeclare?  

I suppose I can always load test it to find out too!

iain

On Fri, Dec 31, 2021 at 2:30 AM Dr. Richard Boulanger <rboulanger@berklee.edu> wrote:

Backward compatibility would suggest that you support both. Please.  The invalue opcode was first and much of my early "csound for live" work uses invalue.   (Now, in Cabbage, my students and I are always using the newer chnset/chnget opcodes.)

Dr. Richard Boulanger

Professor

Electronic Production and Design

Berklee College of Music

On Dec 31, 2021, at 3:46 AM, Tarmo Johannes <trmjhnns@gmail.com> wrote:



Hi!

CsoundQt uses both options for communicating with UI widgets. invalue requires setting callback functions that deal with the channel values, chnget uses directly the Csound API. The latter is more efficient and easier to use, I suggest go with chnget/chnset unless you need more control over the values or want to support both for the user's sake.

chnget/chnset need in most cases that user declares the channels with chn_k (or similar) opcode in their csd

Greetings,

tarmo

Kontakt Iain Duncan (<iainduncanlists@gmail.com>) kirjutas kuupäeval R, 31. detsember 2021 kell 04:34:

Hi folks, I'm plonking away on the Max port of csound6~, and I see there are two ways of getting key/value settings in, invalue opcode controls through the "control" message and chnget opcodes through the "chnset" message. I've looked at the manual, but would like to know more about the difference between these two. If anyone could tell me more or point me at resources on why/when/for-what one would choose one over the other, that would be lovely!

iain

you could say "backwards compatibility", which is probably quite accurate insofar it signals our strict policy of not breaking people's code.

Prof. Victor Lazzarini

Maynooth University

Ireland

On 31 Dec 2021, at 21:01, Iain Duncan <iainduncanlists@gmail.com> wrote:



ok thanks, I shall say "for historical reasons" in help file, ha. I remember that period well. The only thing I see having to change so far is the use of the "set" selector to declare channels, as "set" should be reserved in Max to match other objects. I'm thinking I'll use the "controls" selector to declare controls, as they are set with the "control" selector. 

iain

On Fri, Dec 31, 2021 at 9:50 AM Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:

They both exist because we did not have a good curation system for contributions back then.

Someone contributed invalue/outvalue. Then Istvan Varga ignored it and wrote the named channel bus system alongside it.

So we ended up with this duplication. We have to keep both systems because of backward compatibility. For 7 we should think of a way in which invalue/outvalue are just aliases of chnget/chnset.

Prof. Victor Lazzarini

Maynooth University

Ireland

On 31 Dec 2021, at 16:35, Iain Duncan <iainduncanlists@gmail.com> wrote:



*Warning*

This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.

Thanks folks. I'm porting both, and I understand the API differences (from Victor's code for csound6~ for Pd). My question was more the practical differences so that I can explain why they both exist in the help file. For example, Tarmo said "unless you need more control". Is there a practical difference to the *user*, aside from the fact that one doesn't need to predeclare?  

I suppose I can always load test it to find out too!

iain

On Fri, Dec 31, 2021 at 2:30 AM Dr. Richard Boulanger <rboulanger@berklee.edu> wrote:

Backward compatibility would suggest that you support both. Please.  The invalue opcode was first and much of my early "csound for live" work uses invalue.   (Now, in Cabbage, my students and I are always using the newer chnset/chnget opcodes.)

Dr. Richard Boulanger

Professor

Electronic Production and Design

Berklee College of Music

On Dec 31, 2021, at 3:46 AM, Tarmo Johannes <trmjhnns@gmail.com> wrote:



Hi!

CsoundQt uses both options for communicating with UI widgets. invalue requires setting callback functions that deal with the channel values, chnget uses directly the Csound API. The latter is more efficient and easier to use, I suggest go with chnget/chnset unless you need more control over the values or want to support both for the user's sake.

chnget/chnset need in most cases that user declares the channels with chn_k (or similar) opcode in their csd

Greetings,

tarmo

Kontakt Iain Duncan (<iainduncanlists@gmail.com>) kirjutas kuupäeval R, 31. detsember 2021 kell 04:34:

Hi folks, I'm plonking away on the Max port of csound6~, and I see there are two ways of getting key/value settings in, invalue opcode controls through the "control" message and chnget opcodes through the "chnset" message. I've looked at the manual, but would like to know more about the difference between these two. If anyone could tell me more or point me at resources on why/when/for-what one would choose one over the other, that would be lovely!

iain

Absolutely right.
I’m wondering actually if you could dispense with all the complication by writing a callback that dispatches
anything coming through invalue/outvalue into named bus channels. That is, just call the Csound API function to
set/get the requested named channel. Then you don’t need to keep your own lists. It’s different from how I treated
it way back when csoundapi~ was written but it might work ok.
========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 1 Jan 2022, at 02:36, Iain Duncan <iainduncanlists@GMAIL.COM> wrote:
>
> Well, I have invalue  working now (or at least acting like it is), but I would like to strongly voice my support for Victor's suggestion of aliasing chnget in the future as a replacement. Having csound traverse a linked list in the Max external's code space to get values seems very risky compared to the API approach, and definitely makes the external's code much bigger and complex than it needs to be. I'm also really not sure if this is Max thread safe - in Pd the externals are running in a single thread, but in Max, the audio renderer can be a in a different thread. The Max documentation is unfortunately rather lacking in explaining exactly when one does and does not need to be worrying about it. All in all, it would be much better from a maintenance standpoint to dispense with the callbacks into host space for values every kpass, in my humble opinion. I could also replace the linked list traversal with a Max hashtable to simplify things, but I just don't see how it makes any sense to be doing this at all instead of one call to csoundSetControlChannel.
>
> In the spirit of backwards support, I'll put it in, but will mark it as not recommended compared to chnget, and only experimentally supported. While I'm up for porting everything in Victor's csound6 object, I'm not up for adding a whole thread protection layer to the already significant complexity of invalue lookup if that design turns out not to be Max safe. All in all, it seems like a design that only make sense for a pre-csound-api version of the external.
>
> thanks for the tips!
> iain
>
>
> On Fri, Dec 31, 2021 at 5:07 PM Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
> you could say "backwards compatibility", which is probably quite accurate insofar it signals our strict policy of not breaking people's code.
>
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
>
>> On 31 Dec 2021, at 21:01, Iain Duncan <iainduncanlists@gmail.com> wrote:
>>
>> 
>> ok thanks, I shall say "for historical reasons" in help file, ha. I remember that period well. The only thing I see having to change so far is the use of the "set" selector to declare channels, as "set" should be reserved in Max to match other objects. I'm thinking I'll use the "controls" selector to declare controls, as they are set with the "control" selector.
>>
>> iain
>>
>>
>>
>> On Fri, Dec 31, 2021 at 9:50 AM Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
>> They both exist because we did not have a good curation system for contributions back then.
>>
>> Someone contributed invalue/outvalue. Then Istvan Varga ignored it and wrote the named channel bus system alongside it.
>>
>> So we ended up with this duplication. We have to keep both systems because of backward compatibility. For 7 we should think of a way in which invalue/outvalue are just aliases of chnget/chnset.
>>
>>
>> Prof. Victor Lazzarini
>> Maynooth University
>> Ireland
>>
>>> On 31 Dec 2021, at 16:35, Iain Duncan <iainduncanlists@gmail.com> wrote:
>>>
>>> 
>>> WARNINGThis email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
>>> Thanks folks. I'm porting both, and I understand the API differences (from Victor's code for csound6~ for Pd). My question was more the practical differences so that I can explain why they both exist in the help file. For example, Tarmo said "unless you need more control". Is there a practical difference to the *user*, aside from the fact that one doesn't need to predeclare? 
>>>
>>> I suppose I can always load test it to find out too!
>>>
>>> iain
>>>
>>>
>>>
>>> On Fri, Dec 31, 2021 at 2:30 AM Dr. Richard Boulanger <rboulanger@berklee.edu> wrote:
>>> Backward compatibility would suggest that you support both. Please.  The invalue opcode was first and much of my early "csound for live" work uses invalue.   (Now, in Cabbage, my students and I are always using the newer chnset/chnget opcodes.)
>>>
>>> Dr. Richard Boulanger
>>> Professor
>>> Electronic Production and Design
>>> Berklee College of Music
>>>
>>>> On Dec 31, 2021, at 3:46 AM, Tarmo Johannes <trmjhnns@gmail.com> wrote:
>>>>
>>>> 
>>>> Hi!
>>>>
>>>> CsoundQt uses both options for communicating with UI widgets. invalue requires setting callback functions that deal with the channel values, chnget uses directly the Csound API. The latter is more efficient and easier to use, I suggest go with chnget/chnset unless you need more control over the values or want to support both for the user's sake.
>>>> chnget/chnset need in most cases that user declares the channels with chn_k (or similar) opcode in their csd
>>>>
>>>> Greetings,
>>>> tarmo
>>>>
>>>> Kontakt Iain Duncan (<iainduncanlists@gmail.com>) kirjutas kuupäeval R, 31. detsember 2021 kell 04:34:
>>>> Hi folks, I'm plonking away on the Max port of csound6~, and I see there are two ways of getting key/value settings in, invalue opcode controls through the "control" message and chnget opcodes through the "chnset" message. I've looked at the manual, but would like to know more about the difference between these two. If anyone could tell me more or point me at resources on why/when/for-what one would choose one over the other, that would be lovely!
>>>>
>>>> iain