[Cs-dev] Channel functions in API

[Cs-dev] Channel functions in API

Date	2013-02-22 06:33
From	Andres Cabrera
Subject	[Cs-dev] Channel functions in API
	Hi, I have noticed that the callback functions for channels have been removed from the API. I'm going to make a case to keep them. I think that to make the bus functions generic and make them accept any data type, the only concurrency-safe mechanism is to implement an asynchronous message passing system, which can't guarantee when the new values will be applied in the engine. (Currently the functions are thread safe when Csound is compiled with gcc because they use atomic operations, however this mechanism will not scale to more complex data types or array. Audio channels use spinlocks which is not ideal). So my proposal for the bus/channel mechanism is: REMOVE: ------- Functionality available in other functions (can be done with getters and setters, the minor efficiency gains might not be worth keeping it, plus it's not thread safe): (Actually should be moved to the private part of the API) PUBLIC int csoundGetChannelPtr(CSOUND , MYFLT p, const char name, int type); List is not really necessary. Hosts should query for relevant channels rather than getting a list: PUBLIC int csoundListChannels(CSOUND , CsoundChannelListEntry lst); PUBLIC void csoundDeleteChannelList(CSOUND , CsoundChannelListEntry lst); Channel parameters are not really useful as they are not enforced. These functions have not been used anywhere (AFAIK), which means they are probably not very useful: PUBLIC int csoundSetControlChannelParams(CSOUND , const char name, int type, MYFLT dflt, MYFLT min, MYFLT max); PUBLIC int csoundGetControlChannelParams(CSOUND , const char name, MYFLT dflt, MYFLT min, MYFLT max); There should be no locks for channels: PUBLIC int csoundGetChannelLock(CSOUND , const char name, int type); Unnecessary (Input vs. output could be implemented as a "namespace" for channels and checked when needed, instead of having to have all these functions): PUBLIC int csoundChanIKSet(CSOUND , MYFLT value, int n); PUBLIC int csoundChanOKGet(CSOUND , MYFLT value, int n); PUBLIC int csoundChanIASet(CSOUND , const MYFLT value, int n); PUBLIC int csoundChanOAGet(CSOUND , MYFLT value, int n); PUBLIC int csoundChanIKSetValue(CSOUND , int channel, MYFLT value); PUBLIC MYFLT csoundChanOKGetValue(CSOUND , int channel); PUBLIC int csoundChanIASetSample(CSOUND , int channel, int frame, MYFLT sample); PUBLIC MYFLT csoundChanOAGetSample(CSOUND , int channel, int frame); Can be removed if there is a channel function that can pass any type and types can be interpreted within the host: PUBLIC int csoundPvsinSet(CSOUND , const PVSDATEXT fin, int n); PUBLIC int csoundPvsoutGet(CSOUND csound, PVSDATEXT fout, int n); STAY: ----- Because they are atomic (are they?) so they offer synchronous control. Is there anyhing that can be done about the locks in the audio getter/setters while keeping things synchronous? PUBLIC MYFLT csoundGetControlChannel(CSOUND csound, const char name); PUBLIC void csoundSetControlChannel(CSOUND csound, const char name, MYFLT val); PUBLIC void csoundGetAudioChannel(CSOUND csound, const char name, MYFLT samples); PUBLIC void csoundSetAudioChannel(CSOUND csound, const char name, MYFLT samples); PUBLIC void csoundSetStringChannel(CSOUND csound, const char name, char string); PUBLIC void csoundGetStringChannel(CSOUND csound, const char name, char string); NEW: ---- PUBLIC int csoundGetChannel(CSOUND csound, const char name, CS_VAR var); The question is, do the CS_VAR need to be preallocated? I would think so, but csound inside could still resize or do whatever it needs to. However, the question of real-time safety and allocation within the callback remains. This should then be implemented using the message passing mechanism I mentioned, making this function asynchronous (blocking until the csound engine has had time to fill the data). PUBLIC int csoundSetChannel(CSOUND csound, const char name, CS_VAR var); What do you think? Cheers, Andres ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net

Date	2013-02-22 07:22
From	Victor Lazzarini
Subject	Re: [Cs-dev] Channel functions in API
	I removed the invalue/outvalue callbacks because I made these opcodes use the channel system. I prefer if we could keep it that way. The other callback for channels (the Varga one) was never operational as far as I can see. I'm happy for it to be reinstated and made operational. Your proposal seems fine to me. I think the functions you proposed to remove really need to go, as they can be sources of confusion for API users. Regards Victor On 22 Feb 2013, at 06:33, Andres Cabrera wrote: > Hi, > > I have noticed that the callback functions for channels have been > removed from the API. I'm going to make a case to keep them. I think > that to make the bus functions generic and make them accept any data > type, the only concurrency-safe mechanism is to implement an > asynchronous message passing system, which can't guarantee when the > new values will be applied in the engine. (Currently the functions are > thread safe when Csound is compiled with gcc because they use atomic > operations, however this mechanism will not scale to more complex data > types or array. Audio channels use spinlocks which is not ideal). So > my proposal for the bus/channel mechanism is: > > REMOVE: > ------- > Functionality available in other functions (can be done with getters > and setters, the minor efficiency gains might not be worth keeping it, > plus it's not thread safe): > (Actually should be moved to the private part of the API) > PUBLIC int csoundGetChannelPtr(CSOUND , > MYFLT p, const char name, int type); > > List is not really necessary. Hosts should query for relevant channels > rather than getting a list: > PUBLIC int csoundListChannels(CSOUND , CsoundChannelListEntry lst); > > PUBLIC void csoundDeleteChannelList(CSOUND , CsoundChannelListEntry lst); > > Channel parameters are not really useful as they are not enforced. > These functions have not been used anywhere (AFAIK), which means they > are probably not very useful: > PUBLIC int csoundSetControlChannelParams(CSOUND , const char name, > int type, MYFLT dflt, > MYFLT min, MYFLT max); > > PUBLIC int csoundGetControlChannelParams(CSOUND , const char name, > MYFLT dflt, MYFLT min, MYFLT max); > > There should be no locks for channels: > PUBLIC int csoundGetChannelLock(CSOUND , > const char name, int type); > > Unnecessary (Input vs. output could be implemented as a "namespace" > for channels and checked when needed, instead of having to have all > these functions): > PUBLIC int csoundChanIKSet(CSOUND , MYFLT value, int n); > > PUBLIC int csoundChanOKGet(CSOUND , MYFLT value, int n); > > PUBLIC int csoundChanIASet(CSOUND , const MYFLT value, int n); > > PUBLIC int csoundChanOAGet(CSOUND , MYFLT value, int n); > > PUBLIC int csoundChanIKSetValue(CSOUND , int channel, MYFLT value); > > PUBLIC MYFLT csoundChanOKGetValue(CSOUND , int channel); > > PUBLIC int csoundChanIASetSample(CSOUND , > int channel, int frame, MYFLT sample); > > PUBLIC MYFLT csoundChanOAGetSample(CSOUND , int channel, int frame); > > Can be removed if there is a channel function that can pass any type > and types can be interpreted within the host: > PUBLIC int csoundPvsinSet(CSOUND , const PVSDATEXT fin, int n); > > PUBLIC int csoundPvsoutGet(CSOUND csound, PVSDATEXT fout, int n); > > STAY: > ----- > Because they are atomic (are they?) so they offer synchronous > control. Is there anyhing that can be done about the locks in the > audio getter/setters while keeping things synchronous? > PUBLIC MYFLT csoundGetControlChannel(CSOUND csound, const char name); > > PUBLIC void csoundSetControlChannel(CSOUND csound, const char > name, MYFLT val); > > PUBLIC void csoundGetAudioChannel(CSOUND csound, const char > name, MYFLT samples); > > PUBLIC void csoundSetAudioChannel(CSOUND csound, const char > name, MYFLT samples); > > PUBLIC void csoundSetStringChannel(CSOUND csound, const char > name, char string); > > PUBLIC void csoundGetStringChannel(CSOUND csound, const char > name, char string); > > NEW: > ---- > PUBLIC int csoundGetChannel(CSOUND csound, const char name, CS_VAR var); > The question is, do the CS_VAR need to be preallocated? I would think > so, but csound inside could still resize or do whatever it needs to. > However, the question of real-time safety and allocation within the > callback remains. This should then be implemented using the message > passing mechanism I mentioned, making this function asynchronous > (blocking until the csound engine has had time to fill the data). > > PUBLIC int csoundSetChannel(CSOUND csound, const char name, CS_VAR var); > > What do you think? > > Cheers, > Andres > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel Dr Victor Lazzarini Senior Lecturer Dept. of Music NUI Maynooth Ireland tel.: +353 1 708 3545 Victor dot Lazzarini AT nuim dot ie ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net

Date	2013-02-22 07:27
From	Victor Lazzarini
Subject	Re: [Cs-dev] Channel functions in API
	Oh, I forgot to say: PUBLIC int csoundChanIKSet(CSOUND , MYFLT value, int n); etc serve the "numbered bus". If we remove them, those opcodes will not be functional. We might want to subsume them into the named bus then (as with invalue/outvalue). But that still needs to be done, I think before removal. Victor On 22 Feb 2013, at 07:22, Victor Lazzarini wrote: > I removed the invalue/outvalue callbacks because I made these opcodes use the channel system. I prefer if we could > keep it that way. The other callback for channels (the Varga one) was never operational as far as I can see. I'm happy > for it to be reinstated and made operational. > > Your proposal seems fine to me. I think the functions you proposed to remove really need to go, as they > can be sources of confusion for API users. > > Regards > > Victor > On 22 Feb 2013, at 06:33, Andres Cabrera wrote: > >> Hi, >> >> I have noticed that the callback functions for channels have been >> removed from the API. I'm going to make a case to keep them. I think >> that to make the bus functions generic and make them accept any data >> type, the only concurrency-safe mechanism is to implement an >> asynchronous message passing system, which can't guarantee when the >> new values will be applied in the engine. (Currently the functions are >> thread safe when Csound is compiled with gcc because they use atomic >> operations, however this mechanism will not scale to more complex data >> types or array. Audio channels use spinlocks which is not ideal). So >> my proposal for the bus/channel mechanism is: >> >> REMOVE: >> ------- >> Functionality available in other functions (can be done with getters >> and setters, the minor efficiency gains might not be worth keeping it, >> plus it's not thread safe): >> (Actually should be moved to the private part of the API) >> PUBLIC int csoundGetChannelPtr(CSOUND , >> MYFLT *p, const char name, int type); >> >> List is not really necessary. Hosts should query for relevant channels >> rather than getting a list: >> PUBLIC int csoundListChannels(CSOUND , CsoundChannelListEntry lst); >> >> PUBLIC void csoundDeleteChannelList(CSOUND , CsoundChannelListEntry lst); >> >> Channel parameters are not really useful as they are not enforced. >> These functions have not been used anywhere (AFAIK), which means they >> are probably not very useful: >> PUBLIC int csoundSetControlChannelParams(CSOUND , const char name, >> int type, MYFLT dflt, >> MYFLT min, MYFLT max); >> >> PUBLIC int csoundGetControlChannelParams(CSOUND , const char name, >> MYFLT dflt, MYFLT min, MYFLT max); >> >> There should be no locks for channels: >> PUBLIC int csoundGetChannelLock(CSOUND , >> const char name, int type); >> >> Unnecessary (Input vs. output could be implemented as a "namespace" >> for channels and checked when needed, instead of having to have all >> these functions): >> PUBLIC int csoundChanIKSet(CSOUND , MYFLT value, int n); >> >> PUBLIC int csoundChanOKGet(CSOUND , MYFLT value, int n); >> >> PUBLIC int csoundChanIASet(CSOUND , const MYFLT value, int n); >> >> PUBLIC int csoundChanOAGet(CSOUND , MYFLT value, int n); >> >> PUBLIC int csoundChanIKSetValue(CSOUND , int channel, MYFLT value); >> >> PUBLIC MYFLT csoundChanOKGetValue(CSOUND , int channel); >> >> PUBLIC int csoundChanIASetSample(CSOUND , >> int channel, int frame, MYFLT sample); >> >> PUBLIC MYFLT csoundChanOAGetSample(CSOUND , int channel, int frame); >> >> Can be removed if there is a channel function that can pass any type >> and types can be interpreted within the host: >> PUBLIC int csoundPvsinSet(CSOUND , const PVSDATEXT fin, int n); >> >> PUBLIC int csoundPvsoutGet(CSOUND csound, PVSDATEXT fout, int n); >> >> STAY: >> ----- >> Because they are atomic (are they?) so they offer synchronous >> control. Is there anyhing that can be done about the locks in the >> audio getter/setters while keeping things synchronous? >> PUBLIC MYFLT csoundGetControlChannel(CSOUND csound, const char name); >> >> PUBLIC void csoundSetControlChannel(CSOUND csound, const char >> name, MYFLT val); >> >> PUBLIC void csoundGetAudioChannel(CSOUND csound, const char >> name, MYFLT samples); >> >> PUBLIC void csoundSetAudioChannel(CSOUND csound, const char >> name, MYFLT samples); >> >> PUBLIC void csoundSetStringChannel(CSOUND csound, const char >> name, char string); >> >> PUBLIC void csoundGetStringChannel(CSOUND csound, const char >> name, char string); >> >> NEW: >> ---- >> PUBLIC int csoundGetChannel(CSOUND csound, const char name, CS_VAR var); >> The question is, do the CS_VAR need to be preallocated? I would think >> so, but csound inside could still resize or do whatever it needs to. >> However, the question of real-time safety and allocation within the >> callback remains. This should then be implemented using the message >> passing mechanism I mentioned, making this function asynchronous >> (blocking until the csound engine has had time to fill the data). >> >> PUBLIC int csoundSetChannel(CSOUND csound, const char name, CS_VAR var); >> >> What do you think? >> >> Cheers, >> Andres >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_d2d_feb >> _______________________________________________ >> Csound-devel mailing list >> Csound-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/csound-devel > > Dr Victor Lazzarini > Senior Lecturer > Dept. of Music > NUI Maynooth Ireland > tel.: +353 1 708 3545 > Victor dot Lazzarini AT nuim dot ie > > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel Dr Victor Lazzarini Senior Lecturer Dept. of Music NUI Maynooth Ireland tel.: +353 1 708 3545 Victor dot Lazzarini AT nuim dot ie ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net

Date	2013-02-23 15:45
From	Andres Cabrera
Subject	Re: [Cs-dev] Channel functions in API
	OK, I'll add the callback mechanism for the chn functions, and wrap the invalue/outvalue opcodes with this one. What do you think about the issue with complex type passing to/from the engine (and having an asynchronous message queue)? Cheers, Andrés On Thu, Feb 21, 2013 at 11:22 PM, Victor Lazzarini wrote: > I removed the invalue/outvalue callbacks because I made these opcodes use the channel system. I prefer if we could > keep it that way. The other callback for channels (the Varga one) was never operational as far as I can see. I'm happy > for it to be reinstated and made operational. > > Your proposal seems fine to me. I think the functions you proposed to remove really need to go, as they > can be sources of confusion for API users. > > Regards > > Victor > On 22 Feb 2013, at 06:33, Andres Cabrera wrote: > >> Hi, >> >> I have noticed that the callback functions for channels have been >> removed from the API. I'm going to make a case to keep them. I think >> that to make the bus functions generic and make them accept any data >> type, the only concurrency-safe mechanism is to implement an >> asynchronous message passing system, which can't guarantee when the >> new values will be applied in the engine. (Currently the functions are >> thread safe when Csound is compiled with gcc because they use atomic >> operations, however this mechanism will not scale to more complex data >> types or array. Audio channels use spinlocks which is not ideal). So >> my proposal for the bus/channel mechanism is: >> >> REMOVE: >> ------- >> Functionality available in other functions (can be done with getters >> and setters, the minor efficiency gains might not be worth keeping it, >> plus it's not thread safe): >> (Actually should be moved to the private part of the API) >> PUBLIC int csoundGetChannelPtr(CSOUND , >> MYFLT p, const char name, int type); >> >> List is not really necessary. Hosts should query for relevant channels >> rather than getting a list: >> PUBLIC int csoundListChannels(CSOUND , CsoundChannelListEntry lst); >> >> PUBLIC void csoundDeleteChannelList(CSOUND , CsoundChannelListEntry lst); >> >> Channel parameters are not really useful as they are not enforced. >> These functions have not been used anywhere (AFAIK), which means they >> are probably not very useful: >> PUBLIC int csoundSetControlChannelParams(CSOUND , const char name, >> int type, MYFLT dflt, >> MYFLT min, MYFLT max); >> >> PUBLIC int csoundGetControlChannelParams(CSOUND , const char name, >> MYFLT dflt, MYFLT min, MYFLT max); >> >> There should be no locks for channels: >> PUBLIC int csoundGetChannelLock(CSOUND , >> const char name, int type); >> >> Unnecessary (Input vs. output could be implemented as a "namespace" >> for channels and checked when needed, instead of having to have all >> these functions): >> PUBLIC int csoundChanIKSet(CSOUND , MYFLT value, int n); >> >> PUBLIC int csoundChanOKGet(CSOUND , MYFLT value, int n); >> >> PUBLIC int csoundChanIASet(CSOUND , const MYFLT value, int n); >> >> PUBLIC int csoundChanOAGet(CSOUND , MYFLT value, int n); >> >> PUBLIC int csoundChanIKSetValue(CSOUND , int channel, MYFLT value); >> >> PUBLIC MYFLT csoundChanOKGetValue(CSOUND , int channel); >> >> PUBLIC int csoundChanIASetSample(CSOUND , >> int channel, int frame, MYFLT sample); >> >> PUBLIC MYFLT csoundChanOAGetSample(CSOUND , int channel, int frame); >> >> Can be removed if there is a channel function that can pass any type >> and types can be interpreted within the host: >> PUBLIC int csoundPvsinSet(CSOUND , const PVSDATEXT fin, int n); >> >> PUBLIC int csoundPvsoutGet(CSOUND csound, PVSDATEXT fout, int n); >> >> STAY: >> ----- >> Because they are atomic (are they?) so they offer synchronous >> control. Is there anyhing that can be done about the locks in the >> audio getter/setters while keeping things synchronous? >> PUBLIC MYFLT csoundGetControlChannel(CSOUND csound, const char name); >> >> PUBLIC void csoundSetControlChannel(CSOUND csound, const char >> name, MYFLT val); >> >> PUBLIC void csoundGetAudioChannel(CSOUND csound, const char >> name, MYFLT samples); >> >> PUBLIC void csoundSetAudioChannel(CSOUND csound, const char >> name, MYFLT samples); >> >> PUBLIC void csoundSetStringChannel(CSOUND csound, const char >> name, char string); >> >> PUBLIC void csoundGetStringChannel(CSOUND csound, const char >> name, char string); >> >> NEW: >> ---- >> PUBLIC int csoundGetChannel(CSOUND csound, const char name, CS_VAR var); >> The question is, do the CS_VAR need to be preallocated? I would think >> so, but csound inside could still resize or do whatever it needs to. >> However, the question of real-time safety and allocation within the >> callback remains. This should then be implemented using the message >> passing mechanism I mentioned, making this function asynchronous >> (blocking until the csound engine has had time to fill the data). >> >> PUBLIC int csoundSetChannel(CSOUND csound, const char name, CS_VAR var); >> >> What do you think? >> >> Cheers, >> Andres >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_d2d_feb >> _______________________________________________ >> Csound-devel mailing list >> Csound-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/csound-devel > > Dr Victor Lazzarini > Senior Lecturer > Dept. of Music > NUI Maynooth Ireland > tel.: +353 1 708 3545 > Victor dot Lazzarini AT nuim dot ie > > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net https://lists.sourceforge.n

Date	2013-02-23 15:46
From	Andres Cabrera
Subject	Re: [Cs-dev] Channel functions in API
	I was thinking of doing this as a namespace within the channel list. Cheers, Andrés On Thu, Feb 21, 2013 at 11:27 PM, Victor Lazzarini wrote: > Oh, I forgot to say: > > PUBLIC int csoundChanIKSet(CSOUND , MYFLT value, int n); > > etc > > serve the "numbered bus". If we remove them, those opcodes will not be functional. We might > want to subsume them into the named bus then (as with invalue/outvalue). But that still needs to be done, > I think before removal. > > Victor > On 22 Feb 2013, at 07:22, Victor Lazzarini wrote: > >> I removed the invalue/outvalue callbacks because I made these opcodes use the channel system. I prefer if we could >> keep it that way. The other callback for channels (the Varga one) was never operational as far as I can see. I'm happy >> for it to be reinstated and made operational. >> >> Your proposal seems fine to me. I think the functions you proposed to remove really need to go, as they >> can be sources of confusion for API users. >> >> Regards >> >> Victor >> On 22 Feb 2013, at 06:33, Andres Cabrera wrote: >> >>> Hi, >>> >>> I have noticed that the callback functions for channels have been >>> removed from the API. I'm going to make a case to keep them. I think >>> that to make the bus functions generic and make them accept any data >>> type, the only concurrency-safe mechanism is to implement an >>> asynchronous message passing system, which can't guarantee when the >>> new values will be applied in the engine. (Currently the functions are >>> thread safe when Csound is compiled with gcc because they use atomic >>> operations, however this mechanism will not scale to more complex data >>> types or array. Audio channels use spinlocks which is not ideal). So >>> my proposal for the bus/channel mechanism is: >>> >>> REMOVE: >>> ------- >>> Functionality available in other functions (can be done with getters >>> and setters, the minor efficiency gains might not be worth keeping it, >>> plus it's not thread safe): >>> (Actually should be moved to the private part of the API) >>> PUBLIC int csoundGetChannelPtr(CSOUND , >>> MYFLT *p, const char name, int type); >>> >>> List is not really necessary. Hosts should query for relevant channels >>> rather than getting a list: >>> PUBLIC int csoundListChannels(CSOUND , CsoundChannelListEntry lst); >>> >>> PUBLIC void csoundDeleteChannelList(CSOUND , CsoundChannelListEntry lst); >>> >>> Channel parameters are not really useful as they are not enforced. >>> These functions have not been used anywhere (AFAIK), which means they >>> are probably not very useful: >>> PUBLIC int csoundSetControlChannelParams(CSOUND , const char name, >>> int type, MYFLT dflt, >>> MYFLT min, MYFLT max); >>> >>> PUBLIC int csoundGetControlChannelParams(CSOUND , const char name, >>> MYFLT dflt, MYFLT min, MYFLT max); >>> >>> There should be no locks for channels: >>> PUBLIC int csoundGetChannelLock(CSOUND , >>> const char name, int type); >>> >>> Unnecessary (Input vs. output could be implemented as a "namespace" >>> for channels and checked when needed, instead of having to have all >>> these functions): >>> PUBLIC int csoundChanIKSet(CSOUND , MYFLT value, int n); >>> >>> PUBLIC int csoundChanOKGet(CSOUND , MYFLT value, int n); >>> >>> PUBLIC int csoundChanIASet(CSOUND , const MYFLT value, int n); >>> >>> PUBLIC int csoundChanOAGet(CSOUND , MYFLT value, int n); >>> >>> PUBLIC int csoundChanIKSetValue(CSOUND , int channel, MYFLT value); >>> >>> PUBLIC MYFLT csoundChanOKGetValue(CSOUND , int channel); >>> >>> PUBLIC int csoundChanIASetSample(CSOUND , >>> int channel, int frame, MYFLT sample); >>> >>> PUBLIC MYFLT csoundChanOAGetSample(CSOUND , int channel, int frame); >>> >>> Can be removed if there is a channel function that can pass any type >>> and types can be interpreted within the host: >>> PUBLIC int csoundPvsinSet(CSOUND , const PVSDATEXT fin, int n); >>> >>> PUBLIC int csoundPvsoutGet(CSOUND csound, PVSDATEXT fout, int n); >>> >>> STAY: >>> ----- >>> Because they are atomic (are they?) so they offer synchronous >>> control. Is there anyhing that can be done about the locks in the >>> audio getter/setters while keeping things synchronous? >>> PUBLIC MYFLT csoundGetControlChannel(CSOUND csound, const char name); >>> >>> PUBLIC void csoundSetControlChannel(CSOUND csound, const char >>> name, MYFLT val); >>> >>> PUBLIC void csoundGetAudioChannel(CSOUND csound, const char >>> name, MYFLT samples); >>> >>> PUBLIC void csoundSetAudioChannel(CSOUND csound, const char >>> name, MYFLT samples); >>> >>> PUBLIC void csoundSetStringChannel(CSOUND csound, const char >>> name, char string); >>> >>> PUBLIC void csoundGetStringChannel(CSOUND csound, const char >>> name, char string); >>> >>> NEW: >>> ---- >>> PUBLIC int csoundGetChannel(CSOUND csound, const char name, CS_VAR var); >>> The question is, do the CS_VAR need to be preallocated? I would think >>> so, but csound inside could still resize or do whatever it needs to. >>> However, the question of real-time safety and allocation within the >>> callback remains. This should then be implemented using the message >>> passing mechanism I mentioned, making this function asynchronous >>> (blocking until the csound engine has had time to fill the data). >>> >>> PUBLIC int csoundSetChannel(CSOUND csound, const char name, CS_VAR var); >>> >>> What do you think? >>> >>> Cheers, >>> Andres >>> >>> ------------------------------------------------------------------------------ >>> Everyone hates slow websites. So do we. >>> Make your web apps faster with AppDynamics >>> Download AppDynamics Lite for free today: >>> http://p.sf.net/sfu/appdyn_d2d_feb >>> _______________________________________________ >>> Csound-devel mailing list >>> Csound-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/csound-devel >> >> Dr Victor Lazzarini >> Senior Lecturer >> Dept. of Music >> NUI Maynooth Ireland >> tel.: +353 1 708 3545 >> Victor dot Lazzarini AT nuim dot ie >> >> >> >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_d2d_feb >> _______________________________________________ >> Csound-devel mailing list >> Csound-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/csound-devel > > Dr Victor Lazzarini > Senior Lecturer > Dept. of Music > NUI Maynooth Ireland > tel.: +353 1 708 3545 > Victor dot Lazzarini AT nuim dot ie > > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net https://lists.sourceforge

Date	2013-02-23 15:57
From	Victor Lazzarini
Subject	Re: [Cs-dev] Channel functions in API
	I think it's a good idea. I would suggest you can just take over this area and make the changes you see fit. I only did some initial work on this so we had something to show for. On 23 Feb 2013, at 15:45, Andres Cabrera wrote: > What do you think about the issue with complex type passing to/from > the engine (and having an asynchronous message queue)? Dr Victor Lazzarini Senior Lecturer Dept. of Music NUI Maynooth Ireland tel.: +353 1 708 3545 Victor dot Lazzarini AT nuim dot ie ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net

Date	2013-02-23 16:58
From	Rory Walsh
Subject	Re: [Cs-dev] Channel functions in API
	I'm a little late to this thread, but will there be any callback methods for retrieving channel data in Csound6? On 23 February 2013 15:57, Victor Lazzarini wrote: > I think it's a good idea. I would suggest you can just take over this area and make the changes you see fit. I only did some initial work on this so > we had something to show for. > On 23 Feb 2013, at 15:45, Andres Cabrera wrote: > >> What do you think about the issue with complex type passing to/from >> the engine (and having an asynchronous message queue)? > > Dr Victor Lazzarini > Senior Lecturer > Dept. of Music > NUI Maynooth Ireland > tel.: +353 1 708 3545 > Victor dot Lazzarini AT nuim dot ie > > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net

Date	2013-02-23 17:02
From	Victor Lazzarini
Subject	Re: [Cs-dev] Channel functions in API
	Andres is planning it. But there will be only one software bus. Victor On 23 Feb 2013, at 16:58, Rory Walsh wrote: > I'm a little late to this thread, but will there be any callback > methods for retrieving channel data in Csound6? > > On 23 February 2013 15:57, Victor Lazzarini wrote: >> I think it's a good idea. I would suggest you can just take over this area and make the changes you see fit. I only did some initial work on this so >> we had something to show for. >> On 23 Feb 2013, at 15:45, Andres Cabrera wrote: >> >>> What do you think about the issue with complex type passing to/from >>> the engine (and having an asynchronous message queue)? >> >> Dr Victor Lazzarini >> Senior Lecturer >> Dept. of Music >> NUI Maynooth Ireland >> tel.: +353 1 708 3545 >> Victor dot Lazzarini AT nuim dot ie >> >> >> >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_d2d_feb >> _______________________________________________ >> Csound-devel mailing list >> Csound-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/csound-devel > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel Dr Victor Lazzarini Senior Lecturer Dept. of Music NUI Maynooth Ireland tel.: +353 1 708 3545 Victor dot Lazzarini AT nuim dot ie ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net

Date	2013-02-24 18:02
From	Sigurd Saue
Subject	Re: [Cs-dev] Channel functions in API
	I just saw this now, back from vacation: In our VST plugin wrapper for Csound we use csoundListChannels and csoundGetControlChannelParams to auto-populate a generic GUI from any csd file (as long as the channels are declared in the csd file). This is a poor man's Cabbage, but it is very easy to use and works on standard Csound files. Is there an alternative way of doing this without these API functions (and without having to make GUI-specific declararions as in Cabbage)? Sigurd -----Original Message----- From: Andres Cabrera [mailto:mantaraya36@gmail.com] Sent: Friday, February 22, 2013 7:34 AM To: Developer discussions Subject: [Cs-dev] Channel functions in API Hi, I have noticed that the callback functions for channels have been removed from the API. I'm going to make a case to keep them. I think that to make the bus functions generic and make them accept any data type, the only concurrency-safe mechanism is to implement an asynchronous message passing system, which can't guarantee when the new values will be applied in the engine. (Currently the functions are thread safe when Csound is compiled with gcc because they use atomic operations, however this mechanism will not scale to more complex data types or array. Audio channels use spinlocks which is not ideal). So my proposal for the bus/channel mechanism is: REMOVE: ------- Functionality available in other functions (can be done with getters and setters, the minor efficiency gains might not be worth keeping it, plus it's not thread safe): (Actually should be moved to the private part of the API) PUBLIC int csoundGetChannelPtr(CSOUND , MYFLT p, const char name, int type); List is not really necessary. Hosts should query for relevant channels rather than getting a list: PUBLIC int csoundListChannels(CSOUND , CsoundChannelListEntry lst); PUBLIC void csoundDeleteChannelList(CSOUND , CsoundChannelListEntry lst); Channel parameters are not really useful as they are not enforced. These functions have not been used anywhere (AFAIK), which means they are probably not very useful: PUBLIC int csoundSetControlChannelParams(CSOUND , const char name, int type, MYFLT dflt, MYFLT min, MYFLT max); PUBLIC int csoundGetControlChannelParams(CSOUND , const char name, MYFLT dflt, MYFLT min, MYFLT max); There should be no locks for channels: PUBLIC int csoundGetChannelLock(CSOUND , const char name, int type); Unnecessary (Input vs. output could be implemented as a "namespace" for channels and checked when needed, instead of having to have all these functions): PUBLIC int csoundChanIKSet(CSOUND , MYFLT value, int n); PUBLIC int csoundChanOKGet(CSOUND , MYFLT value, int n); PUBLIC int csoundChanIASet(CSOUND , const MYFLT value, int n); PUBLIC int csoundChanOAGet(CSOUND , MYFLT value, int n); PUBLIC int csoundChanIKSetValue(CSOUND , int channel, MYFLT value); PUBLIC MYFLT csoundChanOKGetValue(CSOUND , int channel); PUBLIC int csoundChanIASetSample(CSOUND , int channel, int frame, MYFLT sample); PUBLIC MYFLT csoundChanOAGetSample(CSOUND , int channel, int frame); Can be removed if there is a channel function that can pass any type and types can be interpreted within the host: PUBLIC int csoundPvsinSet(CSOUND , const PVSDATEXT fin, int n); PUBLIC int csoundPvsoutGet(CSOUND csound, PVSDATEXT fout, int n); STAY: ----- Because they are atomic (are they?) so they offer synchronous control. Is there anyhing that can be done about the locks in the audio getter/setters while keeping things synchronous? PUBLIC MYFLT csoundGetControlChannel(CSOUND csound, const char name); PUBLIC void csoundSetControlChannel(CSOUND csound, const char name, MYFLT val); PUBLIC void csoundGetAudioChannel(CSOUND csound, const char name, MYFLT samples); PUBLIC void csoundSetAudioChannel(CSOUND csound, const char name, MYFLT samples); PUBLIC void csoundSetStringChannel(CSOUND csound, const char name, char string); PUBLIC void csoundGetStringChannel(CSOUND csound, const char name, char string); NEW: ---- PUBLIC int csoundGetChannel(CSOUND csound, const char name, CS_VAR var); The question is, do the CS_VAR need to be preallocated? I would think so, but csound inside could still resize or do whatever it needs to. However, the question of real-time safety and allocation within the callback remains. This should then be implemented using the message passing mechanism I mentioned, making this function asynchronous (blocking until the csound engine has had time to fill the data). PUBLIC int csoundSetChannel(CSOUND csound, const char name, CS_VAR var); What do you think? Cheers, Andres ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/csound-devel ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net

Date	2013-02-24 18:15
From	Victor Lazzarini
Subject	Re: [Cs-dev] Channel functions in API
	If you are using it, we should keep them. Victor On 24 Feb 2013, at 18:02, Sigurd Saue wrote: > I just saw this now, back from vacation: > > In our VST plugin wrapper for Csound we use csoundListChannels and csoundGetControlChannelParams to auto-populate a generic GUI from any csd file (as long as the channels are declared in the csd file). This is a poor man's Cabbage, but it is very easy to use and works on standard Csound files. Is there an alternative way of doing this without these API functions (and without having to make GUI-specific declararions as in Cabbage)? > > Sigurd > > -----Original Message----- > From: Andres Cabrera [mailto:mantaraya36@gmail.com] > Sent: Friday, February 22, 2013 7:34 AM > To: Developer discussions > Subject: [Cs-dev] Channel functions in API > > Hi, > > I have noticed that the callback functions for channels have been removed from the API. I'm going to make a case to keep them. I think that to make the bus functions generic and make them accept any data type, the only concurrency-safe mechanism is to implement an asynchronous message passing system, which can't guarantee when the new values will be applied in the engine. (Currently the functions are thread safe when Csound is compiled with gcc because they use atomic operations, however this mechanism will not scale to more complex data types or array. Audio channels use spinlocks which is not ideal). So my proposal for the bus/channel mechanism is: > > REMOVE: > ------- > Functionality available in other functions (can be done with getters and setters, the minor efficiency gains might not be worth keeping it, plus it's not thread safe): > (Actually should be moved to the private part of the API) > PUBLIC int csoundGetChannelPtr(CSOUND , > MYFLT p, const char name, int type); > > List is not really necessary. Hosts should query for relevant channels rather than getting a list: > PUBLIC int csoundListChannels(CSOUND , CsoundChannelListEntry lst); > > PUBLIC void csoundDeleteChannelList(CSOUND , CsoundChannelListEntry lst); > > Channel parameters are not really useful as they are not enforced. > These functions have not been used anywhere (AFAIK), which means they are probably not very useful: > PUBLIC int csoundSetControlChannelParams(CSOUND , const char name, > int type, MYFLT dflt, > MYFLT min, MYFLT max); > > PUBLIC int csoundGetControlChannelParams(CSOUND , const char name, > MYFLT dflt, MYFLT min, MYFLT max); > > There should be no locks for channels: > PUBLIC int csoundGetChannelLock(CSOUND , > const char name, int type); > > Unnecessary (Input vs. output could be implemented as a "namespace" > for channels and checked when needed, instead of having to have all these functions): > PUBLIC int csoundChanIKSet(CSOUND , MYFLT value, int n); > > PUBLIC int csoundChanOKGet(CSOUND , MYFLT value, int n); > > PUBLIC int csoundChanIASet(CSOUND , const MYFLT value, int n); > > PUBLIC int csoundChanOAGet(CSOUND , MYFLT value, int n); > > PUBLIC int csoundChanIKSetValue(CSOUND , int channel, MYFLT value); > > PUBLIC MYFLT csoundChanOKGetValue(CSOUND , int channel); > > PUBLIC int csoundChanIASetSample(CSOUND , > int channel, int frame, MYFLT sample); > > PUBLIC MYFLT csoundChanOAGetSample(CSOUND , int channel, int frame); > > Can be removed if there is a channel function that can pass any type and types can be interpreted within the host: > PUBLIC int csoundPvsinSet(CSOUND , const PVSDATEXT fin, int n); > > PUBLIC int csoundPvsoutGet(CSOUND csound, PVSDATEXT fout, int n); > > STAY: > ----- > Because they are atomic (are they?) so they offer synchronous control. Is there anyhing that can be done about the locks in the audio getter/setters while keeping things synchronous? > PUBLIC MYFLT csoundGetControlChannel(CSOUND csound, const char name); > > PUBLIC void csoundSetControlChannel(CSOUND csound, const char name, MYFLT val); > > PUBLIC void csoundGetAudioChannel(CSOUND csound, const char name, MYFLT samples); > > PUBLIC void csoundSetAudioChannel(CSOUND csound, const char name, MYFLT samples); > > PUBLIC void csoundSetStringChannel(CSOUND csound, const char name, char string); > > PUBLIC void csoundGetStringChannel(CSOUND csound, const char name, char string); > > NEW: > ---- > PUBLIC int csoundGetChannel(CSOUND csound, const char name, CS_VAR var); The question is, do the CS_VAR need to be preallocated? I would think so, but csound inside could still resize or do whatever it needs to. > However, the question of real-time safety and allocation within the callback remains. This should then be implemented using the message passing mechanism I mentioned, making this function asynchronous (blocking until the csound engine has had time to fill the data). > > PUBLIC int csoundSetChannel(CSOUND csound, const char name, CS_VAR var); > > What do you think? > > Cheers, > Andres > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel Dr Victor Lazzarini Senior Lecturer Dept. of Music NUI Maynooth Ireland tel.: +353 1 708 3545 Victor dot Lazzarini AT nuim dot ie ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net