Steven Yi wrote:

> instead of putting it out in global scope with ftgen or and
> f-statement in the score, you could check with invalue to see if it's
> been defined (invalue nicely defaults to 0 if no value is assigned),
> and if not, define the table using ftgen.  Something like:
> 
> ...
> 
> itab1 invalue Stable1
> itab2 invalue Stable2
> 
> if (itab1 <= 0) then
>   itab1 ftgen ... ; define a table here
>   outvalue Stable1, itab1
> endif

The problem with this is that by default outvalue just discards the
data, while invalue always returns 0. These opcodes are only useful
if the host application registers invalue/outvalue callbacks, but then
the functionality depends on the actual implementation.
However, if I understand correctly, you want something like i/k-rate
ZAK space indexed by strings, defaulting to zero for undefined
locations ?

> Now, I think invalue doesn't work with S strings (need to check), and

All opcodes that expect a quoted string as input argument should work
with S variables as well (in fact this is completely transparent), although
some may not expect that the variable can change.
What invalue/outvalue really does not support yet is strings as data
rather than just index.

> Stable1 concat "myInstrument_tab1_", i_instr_id

This can be done at i-time with

Stable1 sprintf "myInstrument_tab1_%d", i_instr_id

of course, an opcode for this specific purpose may be more efficient,
but you can already use sprintf/sprintfk to have much of the functionality
of the C version of sprintf.
-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

Steven Yi wrote:

> Well, using invalue and outvalue was a bit hackish in the first place,
> and now at least i know that it's really not usable for this!  I
> didn't try any of the code out I wrote, just speculating.  I think
> your description of a " i/k-rate ZAK space indexed by strings,
> defaulting to zero for undefined locations" is exactly what I am
> interested in, except no zakinit type of operation would be necessary.

How about something like this (of course, "opcode1", "opcode2", and
"funcName" should be renamed - any ideas ?):

         opcode1 Sname, xr
xr      opcode2 Sname

where xr is a variable of type i, k, a, or S.

int     funcName(CSOUND *csound, MYFLT **p, const char *name, int type);

p:

   pointer to a variable of type MYFLT* that will receive a pointer to
   the data

type:

   1: i/k-rate
   2: a-rate
   3: string

return value:

   0 (CSOUND_SUCCESS): no error
   CSOUND_ERROR:       a variable with the same name but different type is
                       already defined, or the name or type is invalid
   CSOUND_MEMORY:      creating the variable failed due to insufficient memory
-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

Steven Yi wrote:

> Well, using invalue/outvalue doesn't sound like a good idea for the
> purpose I mentioned due to what you mentioned, and I seem to remember
> Matt having something like string values in MacCsound now.

I think passing string values by invalue/outvalue in MacCsound is
implemented using strset.

> I had done"csound -z1" and it's opcode signature showed "T" and not "S",
 > and I didn't think they were compatible. Are they?

'T' means a string or i-rate ('S' is string only, and 'U' is string, i-rate,
or k-rate) input. So, if you specify a string as the channel name for invalue
or outvalue, it will be used as it is; it does not matter if it is a constant
in double quotes or {{ }}, or an S-rate variable. If you use an i-rate value
as the channel name instead, it is converted to a string with sprintf().

All the following uses of invalue are equivalent:

Sfoo = "1"
ichn = 1

k1  invalue "1"
k2  invalue {{1}}
k3  invalue Sfoo
k4  invalue 1
k5  invalue ichn
-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

Steven Yi wrote:

> This sounds good, though for the C function I think it might be better
> to get rid of type and let the user handle what to do with the MYFLT. 
> The reasoning I'm thinking is that the Csound code is polymorphic,
> yes?  One can put in an i, k, or a and may want to read it out at
> different rates too, without having to "cast" if they want to read at
> a different than what was put in.  For strings, I think it'd be fine
> to put the burden of responsibility on the user and they'd have to
> just be careful to use really unique Sname's and know if what's going
> in is a MYFLT or String.

I think the type should be checked, because writing to a k-rate
value as if it was a-rate or a string would result in memory corruption.
However, another option is to allow the same name to exist with multiple
types, but this may be confusing.

Here is my current idea of the interface and opcodes (these most probably
need to be changed/renamed). Any suggestions are welcome.

API FUNCTIONS

PUBLIC int csoundGetChannelPtr(CSOUND *csound,
                                MYFLT **p, const char *name, int type);

Stores a pointer to the specified channel in *p. The channel is
automatically created and initialized to zero if it does not exist yet.

'name' must be a non-NULL, non-empty string composed of letters, digits,
and the underscore character, and the first character must be a letter.

'type' should be one of the following:

   1: k-rate  (single MYFLT value)
   2: a-rate  (vector of csoundGetKsmps(csound) MYFLT values)
   3: S-rate  (vector of MYFLT values with enough space for storing
               csoundGetStrVarMaxLen(csound) - 1 characters)

Note: types 2 and 3 should only be used after the orchestra is
successfully compiled with csoundCompile(), otherwise the vector
sizes are undefined.

Returns zero on success, or one of the following error codes:

   CSOUND_ERROR        invalid parameters
   CSOUND_MEMORY       memory allocation failure
   any positive value  the channel already exists with a different type
                       that is returned as the error code

PUBLIC int csoundListChannels(CSOUND *csound, char ***names, int **types);

Creates an alphabetically sorted list of all available channels,
storing names in *names, and types (see above) in *types; (*types)[n]
corresponds to (*names)[n]. If not NULL, both arrays should be freed
when no longer needed with free().
Returns the number of channels, possibly zero if there are none,
or a negative error code.

OPCODES

       chn_k Sname
       chn_a Sname
       chn_S Sname

Allocate a k-, a-, or S-rate channel with the specified name.
If it already exists with the same type, the opcode is ignored,
however, an init error occurs if the channel exists with a different type.

ival  getchn Sname
kval  getchn Sname
aval  getchn Sname
Sval  getchn Sname

Read from a channel (allocated if does not exist yet);
the type must be compatible.

       setchn Sname, ival
       setchn Sname, kval
       setchn Sname, aval
       setchn Sname, Sval

Write to a channel. If it does not exist yet, it is allocated,
otherwise the type must be compatible.
-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

>> Well, using invalue/outvalue doesn't sound like a good idea for the
>> purpose I mentioned due to what you mentioned, and I seem to remember
>> Matt having something like string values in MacCsound now.
>
> I think passing string values by invalue/outvalue in MacCsound is
> implemented using strset.

sorry i just caught this thread.  i actually have a new opcode:

outvaluestr "channel name", "out string"

-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

Matt J. Ingalls wrote:

> sorry i just caught this thread.  i actually have a new opcode:
> 
> outvaluestr "channel name", "out string"

Did you also read the other post about the new API functions
and opcodes ?
-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

So, does anyone have comments ? If no one is interested, I will
remove what code is already there.

Istvan Varga wrote:

> Here is my current idea of the interface and opcodes (these most probably
> need to be changed/renamed). Any suggestions are welcome.
> 
> API FUNCTIONS
> 
> PUBLIC int csoundGetChannelPtr(CSOUND *csound,
>                                MYFLT **p, const char *name, int type);
> 
> Stores a pointer to the specified channel in *p. The channel is
> automatically created and initialized to zero if it does not exist yet.
> 
> 'name' must be a non-NULL, non-empty string composed of letters, digits,
> and the underscore character, and the first character must be a letter.
> 
> 'type' should be one of the following:
> 
>   1: k-rate  (single MYFLT value)
>   2: a-rate  (vector of csoundGetKsmps(csound) MYFLT values)
>   3: S-rate  (vector of MYFLT values with enough space for storing
>               csoundGetStrVarMaxLen(csound) - 1 characters)
> 
> Note: types 2 and 3 should only be used after the orchestra is
> successfully compiled with csoundCompile(), otherwise the vector
> sizes are undefined.
> 
> Returns zero on success, or one of the following error codes:
> 
>   CSOUND_ERROR        invalid parameters
>   CSOUND_MEMORY       memory allocation failure
>   any positive value  the channel already exists with a different type
>                       that is returned as the error code
> 
> PUBLIC int csoundListChannels(CSOUND *csound, char ***names, int **types);
> 
> Creates an alphabetically sorted list of all available channels,
> storing names in *names, and types (see above) in *types; (*types)[n]
> corresponds to (*names)[n]. If not NULL, both arrays should be freed
> when no longer needed with free().
> Returns the number of channels, possibly zero if there are none,
> or a negative error code.
> 
> OPCODES
> 
>       chn_k Sname
>       chn_a Sname
>       chn_S Sname
> 
> Allocate a k-, a-, or S-rate channel with the specified name.
> If it already exists with the same type, the opcode is ignored,
> however, an init error occurs if the channel exists with a different type.
> 
> ival  getchn Sname
> kval  getchn Sname
> aval  getchn Sname
> Sval  getchn Sname
> 
> Read from a channel (allocated if does not exist yet);
> the type must be compatible.
> 
>       setchn Sname, ival
>       setchn Sname, kval
>       setchn Sname, aval
>       setchn Sname, Sval
> 
> Write to a channel. If it does not exist yet, it is allocated,
> otherwise the type must be compatible.

-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

Well, having no reponse I think I will remove the functions for now.

Istvan Varga wrote:

> So, does anyone have comments ? If no one is interested, I will
> remove what code is already there.
> 
> Istvan Varga wrote:
> 
>> Here is my current idea of the interface and opcodes (these most probably
>> need to be changed/renamed). Any suggestions are welcome.
>>
>> API FUNCTIONS
>>
>> PUBLIC int csoundGetChannelPtr(CSOUND *csound,
>>                                MYFLT **p, const char *name, int type);
>>
>> Stores a pointer to the specified channel in *p. The channel is
>> automatically created and initialized to zero if it does not exist yet.
>>
>> 'name' must be a non-NULL, non-empty string composed of letters, digits,
>> and the underscore character, and the first character must be a letter.
>>
>> 'type' should be one of the following:
>>
>>   1: k-rate  (single MYFLT value)
>>   2: a-rate  (vector of csoundGetKsmps(csound) MYFLT values)
>>   3: S-rate  (vector of MYFLT values with enough space for storing
>>               csoundGetStrVarMaxLen(csound) - 1 characters)
>>
>> Note: types 2 and 3 should only be used after the orchestra is
>> successfully compiled with csoundCompile(), otherwise the vector
>> sizes are undefined.
>>
>> Returns zero on success, or one of the following error codes:
>>
>>   CSOUND_ERROR        invalid parameters
>>   CSOUND_MEMORY       memory allocation failure
>>   any positive value  the channel already exists with a different type
>>                       that is returned as the error code
>>
>> PUBLIC int csoundListChannels(CSOUND *csound, char ***names, int 
>> **types);
>>
>> Creates an alphabetically sorted list of all available channels,
>> storing names in *names, and types (see above) in *types; (*types)[n]
>> corresponds to (*names)[n]. If not NULL, both arrays should be freed
>> when no longer needed with free().
>> Returns the number of channels, possibly zero if there are none,
>> or a negative error code.
>>
>> OPCODES
>>
>>       chn_k Sname
>>       chn_a Sname
>>       chn_S Sname
>>
>> Allocate a k-, a-, or S-rate channel with the specified name.
>> If it already exists with the same type, the opcode is ignored,
>> however, an init error occurs if the channel exists with a different 
>> type.
>>
>> ival  getchn Sname
>> kval  getchn Sname
>> aval  getchn Sname
>> Sval  getchn Sname
>>
>> Read from a channel (allocated if does not exist yet);
>> the type must be compatible.
>>
>>       setchn Sname, ival
>>       setchn Sname, kval
>>       setchn Sname, aval
>>       setchn Sname, Sval
>>
>> Write to a channel. If it does not exist yet, it is allocated,
>> otherwise the type must be compatible.
> 
> 

-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

> Did you also read the other post about the new API functions
> and opcodes ?

some of it at least.  is this a replacement of invalue/outvalue or what?

i have proposed a number of times here to consolidate invalue/outvalue 
with inch/outch.  is what you are proposing become this?

the only issue that i can think of is what happens with multiple instances 
of csound?  are these channels shared by the instances or private? [ i 
could see wanting both]

-m

-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

Matt J. Ingalls wrote:

> some of it at least.  is this a replacement of invalue/outvalue or what?

Not exactly, as invalue/outvalue are based on callback functions
expected to be implemented by the host application, and also do not
allow the use of different data types.
What I suggested was more like named "variables" that can be accessed
from the orchestra and through the API as well, and can be of more than
one type (k-rate, a-rate, and string).
It may also make sense to improve the callback mechanism of invalue
and outvalue to allow for more generic messages rather than just
single MYFLT values.

> the only issue that i can think of is what happens with multiple 
> instances of csound?  are these channels shared by the instances or 
> private? [ i could see wanting both]

The channels are private. It may also be possible to implement shared
access, although correct synchronization may be a problem. Of course,
the host application can also "connect" separate instances by reading
-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

yes but those differences are minor.  in my host code i keep a database 
of the channel names and the GUI and csound run in separate threads 
reading/writing to the database in their own time...

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.

On Fri, 9 Sep 2005, Istvan Varga wrote:

> Matt J. Ingalls wrote:
>
>> some of it at least.  is this a replacement of invalue/outvalue or what?
>
> Not exactly, as invalue/outvalue are based on callback functions
> expected to be implemented by the host application, and also do not
> allow the use of different data types.
> What I suggested was more like named "variables" that can be accessed
> from the orchestra and through the API as well, and can be of more than
> one type (k-rate, a-rate, and string).
> It may also make sense to improve the callback mechanism of invalue
> and outvalue to allow for more generic messages rather than just
> single MYFLT values.
>
>> the only issue that i can think of is what happens with multiple instances 
>> of csound?  are these channels shared by the instances or private? [ i 
>> could see wanting both]
>
> The channels are private. It may also be possible to implement shared
> access, although correct synchronization may be a problem. Of course,
> the host application can also "connect" separate instances by reading
> -- 
> Send bugs reports to this list.
> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
>
-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk