i need instring/outstring opcodes comparable to invalue/outvalue

Unless i am missing something, it looks like it is going to be too much
of a pain to use the software bus, as my frontend is designed around
csound sending the fronend invalue/outvalue via callbacks whereas
if i use the software bus my frontend has to call csound.

Any strong objection to me adding instring/outstring
opcodes and their partner functions in the API?

Thanks,
Matt;
________________________
           matt  ingalls
http://sonomatics.com



_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

 > It is a pity though that my work on the software bus is wasted.

It's certainly not wasted. That's how all my front ends communicate with 
csound and it's nice and easy to use too.

Rory.


Istvan Varga wrote:
> Well, if adding redundant features cannot be avoided, would it be
> possible for the opcode names not to begin with 'i' ?
> 
> Also, rather than adding new opcodes and a new set of API functions
> for any future types, it may be preferred to extend the
> invalue/outvalue opcodes to be able to handle multiple types, and
> add a type argument to the callbacks.
> 
> It is a pity though that my work on the software bus is wasted.
> 
> On Friday 26 May 2006 21:24, Matt Ingalls wrote:
> 
>> i need instring/outstring opcodes comparable to invalue/outvalue
>>
>> Unless i am missing something, it looks like it is going to be too much
>> of a pain to use the software bus, as my frontend is designed around
>> csound sending the fronend invalue/outvalue via callbacks whereas
>> if i use the software bus my frontend has to call csound.
>>
>> Any strong objection to me adding instring/outstring
>> opcodes and their partner functions in the API?
> 
> 
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 


_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

If there is a way to enhance the current API
functs without breaking existing hosts, i am all for it -
but i can't think of a way other than what i currently do with
csound4, which is a hack by appending a string at the end
of the channel name and sending a special# for the value
to signal that the string is appended to the channel name.

i'll look into enhancing the current invalue/outvalue opcodes.

As far as duplicating efforts, in my view, MY WORK has been
duplicated!  invalue/outvalue has been in there since michael
and i merged our APIs (2001 was it?)

Read the archives - i pleaded even BEGGED many times on the
dev list to expand the invalue/outvalue opcodes instead of created
an entirely new interface for the bus.  i offered to roll in my code  
from
my frontend app that handles the creation and table of channels
MANY times and, except for Steven Yi, i was completely ignored.

And now i am supposed to trash my work and re-implement the
same functionality with your software bus.  It is you who are wasting
my time!

-m

On May 26, 2006, at 11:58 AM, Istvan Varga wrote:

> Well, if adding redundant features cannot be avoided, would it be
> possible for the opcode names not to begin with 'i' ?
>
> Also, rather than adding new opcodes and a new set of API functions
> for any future types, it may be preferred to extend the
> invalue/outvalue opcodes to be able to handle multiple types, and
> add a type argument to the callbacks.
>
> It is a pity though that my work on the software bus is wasted.
>
> On Friday 26 May 2006 21:24, Matt Ingalls wrote:
>
>> i need instring/outstring opcodes comparable to invalue/outvalue
>>
>> Unless i am missing something, it looks like it is going to be too  
>> much
>> of a pain to use the software bus, as my frontend is designed around
>> csound sending the fronend invalue/outvalue via callbacks whereas
>> if i use the software bus my frontend has to call csound.
>>
>> Any strong objection to me adding instring/outstring
>> opcodes and their partner functions in the API?
>
>
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

using the software bus is unacceptable for me in the short term - i just
do not have time/desire to restructure my program at this point.
i think i will add the hack i mentioned to not change the API, and
will make invalue/outvalue have optional input/output as strings.

==

and i think what i was attempting to say in what you quoted below
is what i have always advocated, to reduce all the
in/out/chn/chan/outvalue/zak/etc family opcodes into just 2:

xsig in Schan		; Schan is a channel name or number
      out Schan, xsig

of course keep all the "replaced" opcodes for backwards compatibility
[ internally they would probably just call "in" or "out" ]

but i have stopped trying to push for a consolidated "core opcodes"
family, as it seems people aren't bothered by bloat like i am..

-m

On May 26, 2006, at 1:15 PM, Istvan Varga wrote:

> I may have missed some of these discussions, but the last time,
> when the 'chn' opcodes were added, you wrote about them "but i
> think in the end would be a replacement of invalue/outvalue and
> zak too really - as well as the proposed bussing system [ has
> that ever been finished? ] i'm fine with replacing with
> invalue/outvalue -- but i do think it would be VERY nice if zak
> and buss [ and even inch/outch ] were replaced as well, so we
> get ONE system". I interpreted this as invalue and outvalue not
> being very important: they should be kept for compatibility, but
> not extended.
>
> If using the software bus is really unacceptable, it is possible
> to:
>   - create new extended API functions for invalue/outvalue, and
>     optionally make the old k-rate only ones deprecated (i.e.
>     scheduled for removal when the API major version is
>     increased)
>   - implement hacks like the one described below that allow for
>     passing strings even with the already existing callbacks
>
> On Friday 26 May 2006 22:48, matt ingalls wrote:
>
>> If there is a way to enhance the current API
>> functs without breaking existing hosts, i am all for it -
>> but i can't think of a way other than what i currently do with
>> csound4, which is a hack by appending a string at the end
>> of the channel name and sending a special# for the value
>> to signal that the string is appended to the channel name.
>>
>> i'll look into enhancing the current invalue/outvalue opcodes.
>>
>> As far as duplicating efforts, in my view, MY WORK has been
>> duplicated!  invalue/outvalue has been in there since michael
>> and i merged our APIs (2001 was it?)
>>
>> Read the archives - i pleaded even BEGGED many times on the
>> dev list to expand the invalue/outvalue opcodes instead of created
>> an entirely new interface for the bus.  i offered to roll in my code
>> from
>> my frontend app that handles the creation and table of channels
>> MANY times and, except for Steven Yi, i was completely ignored.
>>
>> And now i am supposed to trash my work and re-implement the
>> same functionality with your software bus.  It is you who are wasting
>> my time!
>
>
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

redundancy is not such a bad thing - it is an essential part of  
incremental learning.

On May 26, 2006, at 6:31 PM, matt ingalls wrote:

> using the software bus is unacceptable for me in the short term - i  
> just
> do not have time/desire to restructure my program at this point.
> i think i will add the hack i mentioned to not change the API, and
> will make invalue/outvalue have optional input/output as strings.
>
> ==
>
> and i think what i was attempting to say in what you quoted below
> is what i have always advocated, to reduce all the
> in/out/chn/chan/outvalue/zak/etc family opcodes into just 2:
>
> xsig in Schan		; Schan is a channel name or number
>       out Schan, xsig
>
> of course keep all the "replaced" opcodes for backwards compatibility
> [ internally they would probably just call "in" or "out" ]
>
> but i have stopped trying to push for a consolidated "core opcodes"
> family, as it seems people aren't bothered by bloat like i am..
>
> -m
>
> On May 26, 2006, at 1:15 PM, Istvan Varga wrote:
>
>> I may have missed some of these discussions, but the last time,
>> when the 'chn' opcodes were added, you wrote about them "but i
>> think in the end would be a replacement of invalue/outvalue and
>> zak too really - as well as the proposed bussing system [ has
>> that ever been finished? ] i'm fine with replacing with
>> invalue/outvalue -- but i do think it would be VERY nice if zak
>> and buss [ and even inch/outch ] were replaced as well, so we
>> get ONE system". I interpreted this as invalue and outvalue not
>> being very important: they should be kept for compatibility, but
>> not extended.
>>
>> If using the software bus is really unacceptable, it is possible
>> to:
>>   - create new extended API functions for invalue/outvalue, and
>>     optionally make the old k-rate only ones deprecated (i.e.
>>     scheduled for removal when the API major version is
>>     increased)
>>   - implement hacks like the one described below that allow for
>>     passing strings even with the already existing callbacks
>>
>> On Friday 26 May 2006 22:48, matt ingalls wrote:
>>
>>> If there is a way to enhance the current API
>>> functs without breaking existing hosts, i am all for it -
>>> but i can't think of a way other than what i currently do with
>>> csound4, which is a hack by appending a string at the end
>>> of the channel name and sending a special# for the value
>>> to signal that the string is appended to the channel name.
>>>
>>> i'll look into enhancing the current invalue/outvalue opcodes.
>>>
>>> As far as duplicating efforts, in my view, MY WORK has been
>>> duplicated!  invalue/outvalue has been in there since michael
>>> and i merged our APIs (2001 was it?)
>>>
>>> Read the archives - i pleaded even BEGGED many times on the
>>> dev list to expand the invalue/outvalue opcodes instead of created
>>> an entirely new interface for the bus.  i offered to roll in my code
>>> from
>>> my frontend app that handles the creation and table of channels
>>> MANY times and, except for Steven Yi, i was completely ignored.
>>>
>>> And now i am supposed to trash my work and re-implement the
>>> same functionality with your software bus.  It is you who are  
>>> wasting
>>> my time!
>>
>>
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
>
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

yea probably to keep things more consistent.
  i did the outvalue hack before the invalue one and
came up with a different system.  i'll change the magic
number to the magic character.

Unless i'm not thinking of something [ no coffee yet this morn ]
i think you still need some kind of separator between the channel
name and the value string as the host side does not necessarily
know about the channel name.

-,,m

On May 29, 2006, at 1:45 AM, Istvan Varga wrote:

> On Saturday 27 May 2006 00:31, matt ingalls wrote:
>
>> i think i will add the hack i mentioned to not change the API, and
>> will make invalue/outvalue have optional input/output as strings.
>
> I noticed the changes are already made. However, for outvalue, would
> it be a good idea if instead of using a "magic number" and appending
> the value after ::, the channel name would begin with '$' (like in
> the case of invalue) and the string value would be copied after the
> NUL character that terminates the channel name ?
>
> Here is an example callback function:
>
> void outputValueCallback(CSOUND *csound, const char *channelName,
>                          MYFLT value)
> {
>     if (channelName[0] == '$') {
>       const char  *stringValue;
>       channelName++;
>       stringValue = &(channelName[strlen(channelName) + 1]);
>       ...
>     }
>     ...
> }
>
>
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

well if you are that concerned about conflicts
maybe using the "magic number" would be better
then using a $ anyway?

let's just keep my code as is and devote
time to something less trivial.

-m

On May 29, 2006, at 9:22 AM, Istvan Varga wrote:

> On Monday 29 May 2006 19:11, matt ingalls wrote:
>
>> yea probably to keep things more consistent.
>>   i did the outvalue hack before the invalue one and
>> came up with a different system.  i'll change the magic
>> number to the magic character.
>
> The alternate method for implementing string values in outvalue
> is already there, just commented out (see below). I also made
> changes to remove any $ characters from the beginning of channel
> names specified by the orchestra, to avoid confusing hosts.



>
>> Unless i'm not thinking of something [ no coffee yet this morn ]
>> i think you still need some kind of separator between the channel
>> name and the value string as the host side does not necessarily
>> know about the channel name.
>
> I do not really know what you mean by the host not knowing about
> the channel name, but the separator in the (disabled) code below
> is the '\0' character at the end of the channel name.
>
> int koutval(CSOUND *csound, OUTVAL *p)
> {
>     if (csound->OutputValueCallback_) {
>       if (p->XSTRCODE & 2) {
>         char  text[2048];
> #if 1
>         /* a hack to support strings */
>         /* FIXME: check for buffer overflow */
>         sprintf(text, "%s::%s", p->channelName, (char*) p->value);
>         /* NOTE: with 32 bit floats, */
>         /* the magic number is rounded to -987654336 */
>         csound->OutputValueCallback_(csound, text, (MYFLT)  
> -987654321);
> #else
>         int   n;
>         /* alternate hack to support strings */
>         /* FIXME: check for buffer overflow */
>         n = sprintf(text, "$%s", p->channelName);
>         strcpy(&(text[n + 1]), (char*) p->value);
>         csound->OutputValueCallback_(csound, text, FL(0.0));
> #endif
>       }
>       else
>         csound->OutputValueCallback_(csound, p->channelName, *(p- 
> >value));
>     }
>
>     return OK;
> }
>
>
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On May 29, 2006, at 12:04 PM, Istvan Varga wrote:

> On Monday 29 May 2006 20:46, matt ingalls wrote:
>
>> well if you are that concerned about conflicts
>> maybe using the "magic number" would be better
>> then using a $ anyway?
>>
>> let's just keep my code as is and devote
>> time to something less trivial.
>
> I did not replace your code yet: the other version is #ifdef-ed
> out at this time. However, as you are already using $ for invalue,
> removing any $ from the orchestra specified channel name is needed
> because otherwise memory corruption would occur when the host tries

OK -- in the future i would appreciate it if you just mention to me  
about any
concerns you may have in my code so i can change it myself,
rather than just going in and fixing it 20 minutes after i have  
checked it in.

And putting FIXME all over it is just flat out rude, even if you
think you are helping.

> to write a string when in fact the orchestra expects a MYFLT.
> I only suggested using the $ for outvalue as well for consistency,
> and having the string value after the '\0' character of the channel
> name is easier to parse, at least in C/C++, and slightly less
> confusing to old hosts that are not aware of string values.

perhaps, although doing a strstr() is about as easy.
plus, using '\0' doesn't let you do string functions like strcpy()
before parsing, and you will not be able to see the entire pair
automatically in a debugger.  also for some reason putting text after a
'\0' just seems too weird to me.

-m




_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net