Hi,

I am writing an opcode and I was just wondering what the magic letters are for intypes for an opcode that takes a string then a variable size of k-rate array and string pairs. 
For example: SFilename, karray1, Sdataset1, karray2, Sdataset2, karray3, Sdataset3,...

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

You will need to use a generic “all inputs” code: m
========================
Dr Victor Lazzarini
Senior Lecturer
NUI Maynooth, Ireland
victor dot lazzarini at nuim dot ie




On 11 Aug 2014, at 11:14, jpff@cs.bath.ac.uk wrote:

> No such code exists
> 
> Quoting Edward Costello :
> 
>> Hi,
>> 
>> I am writing an opcode and I was just wondering what the magic  
>> letters are for intypes for an opcode that takes a string then a  
>> variable size of k-rate array and string pairs.
>> For example: SFilename, karray1, Sdataset1, karray2, Sdataset2,  
>> karray3, Sdataset3,...
>> 
>> Thanks
>> Ed
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> 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

Ok, thanks
Ed

On 11 Aug 2014, at 12:18, Victor Lazzarini  wrote:

> You will need to use a generic “all inputs” code: m
> ========================
> Dr Victor Lazzarini
> Senior Lecturer
> NUI Maynooth, Ireland
> victor dot lazzarini at nuim dot ie
> 
> 
> 
> 
> On 11 Aug 2014, at 11:14, jpff@cs.bath.ac.uk wrote:
> 
>> No such code exists
>> 
>> Quoting Edward Costello :
>> 
>>> Hi,
>>> 
>>> I am writing an opcode and I was just wondering what the magic  
>>> letters are for intypes for an opcode that takes a string then a  
>>> variable size of k-rate array and string pairs.
>>> For example: SFilename, karray1, Sdataset1, karray2, Sdataset2,  
>>> karray3, Sdataset3,...
>>> 
>>> Thanks
>>> Ed
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> 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
> https://lists.sourceforge.net/lists/listinfo/csound-devel


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

My original intypes entry was "Sk[]S”, should it just work if I change it to “m” ? I tried doing that and it’s complaining that it cannot find an opcode with matching argument types.

On 11 Aug 2014, at 13:06, Edward Costello  wrote:

> Ok, thanks
> Ed
> 
> On 11 Aug 2014, at 12:18, Victor Lazzarini  wrote:
> 
>> You will need to use a generic “all inputs” code: m
>> ========================
>> Dr Victor Lazzarini
>> Senior Lecturer
>> NUI Maynooth, Ireland
>> victor dot lazzarini at nuim dot ie
>> 
>> 
>> 
>> 
>> On 11 Aug 2014, at 11:14, jpff@cs.bath.ac.uk wrote:
>> 
>>> No such code exists
>>> 
>>> Quoting Edward Costello :
>>> 
>>>> Hi,
>>>> 
>>>> I am writing an opcode and I was just wondering what the magic  
>>>> letters are for intypes for an opcode that takes a string then a  
>>>> variable size of k-rate array and string pairs.
>>>> For example: SFilename, karray1, Sdataset1, karray2, Sdataset2,  
>>>> karray3, Sdataset3,...
>>>> 
>>>> Thanks
>>>> Ed
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> 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
>> 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

Maybe it's not matching arrays. Steven, shouldn't 'm' match arrays too?


On 11 Aug 2014, at 18:39, Edward Costello wrote:

> My original intypes entry was "Sk[]S”, should it just work if I change it to “m” ? I tried doing that and it’s complaining that it cannot find an opcode with matching argument types.
> 
> On 11 Aug 2014, at 13:06, Edward Costello  wrote:
> 
>> Ok, thanks
>> Ed
>> 
>> On 11 Aug 2014, at 12:18, Victor Lazzarini  wrote:
>> 
>>> You will need to use a generic “all inputs” code: m
>>> ========================
>>> Dr Victor Lazzarini
>>> Senior Lecturer
>>> NUI Maynooth, Ireland
>>> victor dot lazzarini at nuim dot ie
>>> 
>>> 
>>> 
>>> 
>>> On 11 Aug 2014, at 11:14, jpff@cs.bath.ac.uk wrote:
>>> 
>>>> No such code exists
>>>> 
>>>> Quoting Edward Costello :
>>>> 
>>>>> Hi,
>>>>> 
>>>>> I am writing an opcode and I was just wondering what the magic  
>>>>> letters are for intypes for an opcode that takes a string then a  
>>>>> variable size of k-rate array and string pairs.
>>>>> For example: SFilename, karray1, Sdataset1, karray2, Sdataset2,  
>>>>> karray3, Sdataset3,...
>>>>> 
>>>>> Thanks
>>>>> Ed
>>>>> ------------------------------------------------------------------------------
>>>>> _______________________________________________
>>>>> 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
>>> 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
> 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




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

I tried “Sk[]Sm” and that fails, the parser won’t parse the csd with any string array pairs after the first ones. 
As a test I just put in scalar k rate variables after the first array string pair and it worked though, does anyone know where I am going wrong?
Ed

On 11 Aug 2014, at 19:39, Edward Costello  wrote:

> My original intypes entry was "Sk[]S”, should it just work if I change it to “m” ? I tried doing that and it’s complaining that it cannot find an opcode with matching argument types.
> 
> On 11 Aug 2014, at 13:06, Edward Costello  wrote:
> 
>> Ok, thanks
>> Ed
>> 
>> On 11 Aug 2014, at 12:18, Victor Lazzarini  wrote:
>> 
>>> You will need to use a generic “all inputs” code: m
>>> ========================
>>> Dr Victor Lazzarini
>>> Senior Lecturer
>>> NUI Maynooth, Ireland
>>> victor dot lazzarini at nuim dot ie
>>> 
>>> 
>>> 
>>> 
>>> On 11 Aug 2014, at 11:14, jpff@cs.bath.ac.uk wrote:
>>> 
>>>> No such code exists
>>>> 
>>>> Quoting Edward Costello :
>>>> 
>>>>> Hi,
>>>>> 
>>>>> I am writing an opcode and I was just wondering what the magic  
>>>>> letters are for intypes for an opcode that takes a string then a  
>>>>> variable size of k-rate array and string pairs.
>>>>> For example: SFilename, karray1, Sdataset1, karray2, Sdataset2,  
>>>>> karray3, Sdataset3,...
>>>>> 
>>>>> Thanks
>>>>> Ed
>>>>> ------------------------------------------------------------------------------
>>>>> _______________________________________________
>>>>> 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
>>> 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
> https://lists.sourceforge.net/lists/listinfo/csound-devel


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

I think "m" is only matching scalars not arrays. Should it be changed?

Victor
On 11 Aug 2014, at 21:08, Edward Costello wrote:

> I tried “Sk[]Sm” and that fails, the parser won’t parse the csd with any string array pairs after the first ones. 
> As a test I just put in scalar k rate variables after the first array string pair and it worked though, does anyone know where I am going wrong?
> Ed
> 
> On 11 Aug 2014, at 19:39, Edward Costello  wrote:
> 
>> My original intypes entry was "Sk[]S”, should it just work if I change it to “m” ? I tried doing that and it’s complaining that it cannot find an opcode with matching argument types.
>> 
>> On 11 Aug 2014, at 13:06, Edward Costello  wrote:
>> 
>>> Ok, thanks
>>> Ed
>>> 
>>> On 11 Aug 2014, at 12:18, Victor Lazzarini  wrote:
>>> 
>>>> You will need to use a generic “all inputs” code: m
>>>> ========================
>>>> Dr Victor Lazzarini
>>>> Senior Lecturer
>>>> NUI Maynooth, Ireland
>>>> victor dot lazzarini at nuim dot ie
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On 11 Aug 2014, at 11:14, jpff@cs.bath.ac.uk wrote:
>>>> 
>>>>> No such code exists
>>>>> 
>>>>> Quoting Edward Costello :
>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> I am writing an opcode and I was just wondering what the magic  
>>>>>> letters are for intypes for an opcode that takes a string then a  
>>>>>> variable size of k-rate array and string pairs.
>>>>>> For example: SFilename, karray1, Sdataset1, karray2, Sdataset2,  
>>>>>> karray3, Sdataset3,...
>>>>>> 
>>>>>> Thanks
>>>>>> Ed
>>>>>> ------------------------------------------------------------------------------
>>>>>> _______________________________________________
>>>>>> 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
>>>> 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
>> 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

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie




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

I think in this case, maybe Ed could try using * which is a var-arg of
any type.  So maybe try using "S*".  I see that * is in the list of
characters accepted for var-arg in-args. (It looks like I added that
for xout...) I seem to remember a long email to the dev list about
using ? for an optional arg of any type, * for var-arg of any type,
and . for a mandatory arg of any type. This would have been about a
year and a half ago, as I probably wrote about it while we were in the
thick of getting 6.0.0 out the door.

Ed, give that a go and see if that does the job. You could also check
in the init-function of your opcode the types at runtime to verify
that they are the kind you are expecting (k[], s, k[],s[], etc.).

Victor: regarding m, I think we should hold off at the moment.  We
really should get rid of the single-letter args that are representing
var-args and optional-args, and replace it with a more advanced arg
notation, such as:

"akk(43)i(0)k*"

or something like that, where ak would be mandatory, k(43) would be
optional with default value 43, and the last k* would mean var-arg of
k-type.  (That syntax looks horrible, so let's not use it, but it
illustrates the idea.)

Python has nice ways to define var-args and optional-args, i.e.:

def myFunc(var1,var2, var3 = 440, *args):
  doSomething()

There's also some issues in dealing with the older notation, because
the internal system bubbled up to user-level through UDO args.  I did
have an idea that we could freeze the older syntax for instr and
opcode, but introduce new ones with Instr and Opcode (using
capitalized names).  That way, we could change the syntax of UDO's to
be something like:

Opcode MyOpcode (kvar, avar, Sval, asigs[], ksigs[])
  kval = 5
  return kval
end

where return would function similarly to xout.  Also, have named args
would allow easy interop with the type system. Sort of just
speculation though, maybe the syntax is a bit too different, I'm not
sure.


On Mon, Aug 11, 2014 at 4:24 PM, Victor Lazzarini
 wrote:
> I think "m" is only matching scalars not arrays. Should it be changed?
>
> Victor
> On 11 Aug 2014, at 21:08, Edward Costello wrote:
>
>> I tried “Sk[]Sm” and that fails, the parser won’t parse the csd with any string array pairs after the first ones.
>> As a test I just put in scalar k rate variables after the first array string pair and it worked though, does anyone know where I am going wrong?
>> Ed
>>
>> On 11 Aug 2014, at 19:39, Edward Costello  wrote:
>>
>>> My original intypes entry was "Sk[]S”, should it just work if I change it to “m” ? I tried doing that and it’s complaining that it cannot find an opcode with matching argument types.
>>>
>>> On 11 Aug 2014, at 13:06, Edward Costello  wrote:
>>>
>>>> Ok, thanks
>>>> Ed
>>>>
>>>> On 11 Aug 2014, at 12:18, Victor Lazzarini  wrote:
>>>>
>>>>> You will need to use a generic “all inputs” code: m
>>>>> ========================
>>>>> Dr Victor Lazzarini
>>>>> Senior Lecturer
>>>>> NUI Maynooth, Ireland
>>>>> victor dot lazzarini at nuim dot ie
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 11 Aug 2014, at 11:14, jpff@cs.bath.ac.uk wrote:
>>>>>
>>>>>> No such code exists
>>>>>>
>>>>>> Quoting Edward Costello :
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I am writing an opcode and I was just wondering what the magic
>>>>>>> letters are for intypes for an opcode that takes a string then a
>>>>>>> variable size of k-rate array and string pairs.
>>>>>>> For example: SFilename, karray1, Sdataset1, karray2, Sdataset2,
>>>>>>> karray3, Sdataset3,...
>>>>>>>
>>>>>>> Thanks
>>>>>>> Ed
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>> 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
>>> 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
>
> Dr Victor Lazzarini
> Senior Lecturer
> Dept. of Music
> NUI Maynooth Ireland
> tel.: +353 1 708 3545
> Victor dot Lazzarini AT nuim dot ie
>
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> 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/listin

Thanks the * seems to work, although I think there might be something wrong. When I use * for inputs and outputs where the inputs are all strings and the outputs all arrays, I am not able to get a pointer to my strings, they come out NULL, but if I remove the * for the outputs I can pick up the strings fine, is this a limitation?


> On 12 Aug 2014, at 00:07, Steven Yi  wrote:
> 
> I think in this case, maybe Ed could try using * which is a var-arg of
> any type.  So maybe try using "S*".  I see that * is in the list of
> characters accepted for var-arg in-args. (It looks like I added that
> for xout...) I seem to remember a long email to the dev list about
> using ? for an optional arg of any type, * for var-arg of any type,
> and . for a mandatory arg of any type. This would have been about a
> year and a half ago, as I probably wrote about it while we were in the
> thick of getting 6.0.0 out the door.
> 
> Ed, give that a go and see if that does the job. You could also check
> in the init-function of your opcode the types at runtime to verify
> that they are the kind you are expecting (k[], s, k[],s[], etc.).
> 
> Victor: regarding m, I think we should hold off at the moment.  We
> really should get rid of the single-letter args that are representing
> var-args and optional-args, and replace it with a more advanced arg
> notation, such as:
> 
> "akk(43)i(0)k*"
> 
> or something like that, where ak would be mandatory, k(43) would be
> optional with default value 43, and the last k* would mean var-arg of
> k-type.  (That syntax looks horrible, so let's not use it, but it
> illustrates the idea.)
> 
> Python has nice ways to define var-args and optional-args, i.e.:
> 
> def myFunc(var1,var2, var3 = 440, *args):
>  doSomething()
> 
> There's also some issues in dealing with the older notation, because
> the internal system bubbled up to user-level through UDO args.  I did
> have an idea that we could freeze the older syntax for instr and
> opcode, but introduce new ones with Instr and Opcode (using
> capitalized names).  That way, we could change the syntax of UDO's to
> be something like:
> 
> Opcode MyOpcode (kvar, avar, Sval, asigs[], ksigs[])
>  kval = 5
>  return kval
> end
> 
> where return would function similarly to xout.  Also, have named args
> would allow easy interop with the type system. Sort of just
> speculation though, maybe the syntax is a bit too different, I'm not
> sure.
> 
> 
> On Mon, Aug 11, 2014 at 4:24 PM, Victor Lazzarini
>  wrote:
>> I think "m" is only matching scalars not arrays. Should it be changed?
>> 
>> Victor
>> On 11 Aug 2014, at 21:08, Edward Costello wrote:
>> 
>>> I tried “Sk[]Sm” and that fails, the parser won’t parse the csd with any string array pairs after the first ones.
>>> As a test I just put in scalar k rate variables after the first array string pair and it worked though, does anyone know where I am going wrong?
>>> Ed
>>> 
>>> On 11 Aug 2014, at 19:39, Edward Costello  wrote:
>>> 
>>>> My original intypes entry was "Sk[]S”, should it just work if I change it to “m” ? I tried doing that and it’s complaining that it cannot find an opcode with matching argument types.
>>>> 
>>>> On 11 Aug 2014, at 13:06, Edward Costello  wrote:
>>>> 
>>>>> Ok, thanks
>>>>> Ed
>>>>> 
>>>>> On 11 Aug 2014, at 12:18, Victor Lazzarini  wrote:
>>>>> 
>>>>>> You will need to use a generic “all inputs” code: m
>>>>>> ========================
>>>>>> Dr Victor Lazzarini
>>>>>> Senior Lecturer
>>>>>> NUI Maynooth, Ireland
>>>>>> victor dot lazzarini at nuim dot ie
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 11 Aug 2014, at 11:14, jpff@cs.bath.ac.uk wrote:
>>>>>> 
>>>>>>> No such code exists
>>>>>>> 
>>>>>>> Quoting Edward Costello :
>>>>>>> 
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> I am writing an opcode and I was just wondering what the magic
>>>>>>>> letters are for intypes for an opcode that takes a string then a
>>>>>>>> variable size of k-rate array and string pairs.
>>>>>>>> For example: SFilename, karray1, Sdataset1, karray2, Sdataset2,
>>>>>>>> karray3, Sdataset3,...
>>>>>>>> 
>>>>>>>> Thanks
>>>>>>>> Ed
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>> 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
>>>> 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
>> 
>> Dr Victor Lazzarini
>> Senior Lecturer
>> Dept. of Music
>> NUI Maynooth Ireland
>> tel.: +353 1 708 3545
>> Victor dot Lazzarini AT nuim dot ie
>> 
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> 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
https://lists.sourceforge.net/lists/listinfo/csound-deve

I think there might be a bug lurking in here. I built and ran your opcode with the following line

 i1, i2 opcodetest "hello", "hi", “ho"

and this is what the debugger tells me:

Process 97844 stopped
* thread #1: tid = 0x9d9c55, 0x0000000106fe8f15 testop.dylib`opcode_init(csound=0x0000000101001200, self=0x000000010705edf0) + 101 at testop.cpp:19, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x0000000106fe8f15 testop.dylib`opcode_init(csound=0x0000000101001200, self=0x000000010705edf0) + 101 at testop.cpp:19
   16  	    for (size_t i = 0; i < inputArgumentCount; ++i) {
   17  	        
   18  	        STRINGDAT *currentString = (STRINGDAT *) self->inputArgs[i];
-> 19  	        csound->Message(csound, "%s", currentString->data);
   20  	    }
   21  	    
   22  	    return OK;
(lldb) print ((STRINGDAT *)self->outputArgs[2])->data
(char *) $6 = 0x0000000100d7d730 "hello"
(lldb) print ((STRINGDAT *)self->outputArgs[3])->data
(char *) $7 = 0x0000000100d7d840 "hi"
(lldb) print ((STRINGDAT *)self->outputArgs[4])->data
(char *) $8 = 0x0000000100d7d950 “ho"


see? all of the arguments have been passed in the outputArgs[] array. That does not seem right, it looks
like a bug to me (in Csound).

Regards
========================
Dr Victor Lazzarini
Senior Lecturer
NUI Maynooth, Ireland
victor dot lazzarini at nuim dot ie




On 14 Aug 2014, at 18:33, Edward Costello  wrote:

> This is a skeleton of the code I’m using, running this gives a segmentation fault. Am I not constructing the opcode correctly?
> 
> #import 
> 
> typedef struct _opcode
> {
>     OPDS h;
>    
>     MYFLT *outputArgs[VARGMAX]; //arrays
>     MYFLT *inputArgs[VARGMAX]; //strings
>     
> } opcode;
> 
> int opcode_init(CSOUND *csound, opcode *self)
> {
>     size_t inputArgumentCount = self->INOCOUNT;
>     
>     for (size_t i = 0; i < inputArgumentCount; ++i) {
>         
>         STRINGDAT *currentString = (STRINGDAT *) self->inputArgs[i];
>         csound->Message(csound, "%s", currentString->data);
>     }
>     
>     return OK;
> }
> 
> 
> static OENTRY localops[] = {
>     
>     {
>         .opname = "opcodetest",
>         .dsblksiz = sizeof(opcode),
>         .thread = 1,
>         .outypes = "*",
>         .intypes = "*",
>         .iopadr = (SUBR)opcode_init,
>         .kopadr = NULL,
>         .aopadr = NULL
>     }
> };
> 
> LINKAGE
> 
> 
>> On 14 Aug 2014, at 00:31, Edward Costello  wrote:
>> 
>> Thanks the * seems to work, although I think there might be something wrong. When I use * for inputs and outputs where the inputs are all strings and the outputs all arrays, I am not able to get a pointer to my strings, they come out NULL, but if I remove the * for the outputs I can pick up the strings fine, is this a limitation?
>> 
>> 
>>> On 12 Aug 2014, at 00:07, Steven Yi  wrote:
>>> 
>>> I think in this case, maybe Ed could try using * which is a var-arg of
>>> any type.  So maybe try using "S*".  I see that * is in the list of
>>> characters accepted for var-arg in-args. (It looks like I added that
>>> for xout...) I seem to remember a long email to the dev list about
>>> using ? for an optional arg of any type, * for var-arg of any type,
>>> and . for a mandatory arg of any type. This would have been about a
>>> year and a half ago, as I probably wrote about it while we were in the
>>> thick of getting 6.0.0 out the door.
>>> 
>>> Ed, give that a go and see if that does the job. You could also check
>>> in the init-function of your opcode the types at runtime to verify
>>> that they are the kind you are expecting (k[], s, k[],s[], etc.).
>>> 
>>> Victor: regarding m, I think we should hold off at the moment.  We
>>> really should get rid of the single-letter args that are representing
>>> var-args and optional-args, and replace it with a more advanced arg
>>> notation, such as:
>>> 
>>> "akk(43)i(0)k*"
>>> 
>>> or something like that, where ak would be mandatory, k(43) would be
>>> optional with default value 43, and the last k* would mean var-arg of
>>> k-type.  (That syntax looks horrible, so let's not use it, but it
>>> illustrates the idea.)
>>> 
>>> Python has nice ways to define var-args and optional-args, i.e.:
>>> 
>>> def myFunc(var1,var2, var3 = 440, *args):
>>> doSomething()
>>> 
>>> There's also some issues in dealing with the older notation, because
>>> the internal system bubbled up to user-level through UDO args.  I did
>>> have an idea that we could freeze the older syntax for instr and
>>> opcode, but introduce new ones with Instr and Opcode (using
>>> capitalized names).  That way, we could change the syntax of UDO's to
>>> be something like:
>>> 
>>> Opcode MyOpcode (kvar, avar, Sval, asigs[], ksigs[])
>>> kval = 5
>>> return kval
>>> end
>>> 
>>> where return would function similarly to xout.  Also, have named args
>>> would allow easy interop with the type system. Sort of just
>>> speculation though, maybe the syntax is a bit too different, I'm not
>>> sure.
>>> 
>>> 
>>> On Mon, Aug 11, 2014 at 4:24 PM, Victor Lazzarini
>>>  wrote:
>>>> I think "m" is only matching scalars not arrays. Should it be changed?
>>>> 
>>>> Victor
>>>> On 11 Aug 2014, at 21:08, Edward Costello wrote:
>>>> 
>>>>> I tried “Sk[]Sm” and that fails, the parser won’t parse the csd with any string array pairs after the first ones.
>>>>> As a test I just put in scalar k rate variables after the first array string pair and it worked though, does anyone know where I am going wrong?
>>>>> Ed
>>>>> 
>>>>> On 11 Aug 2014, at 19:39, Edward Costello  wrote:
>>>>> 
>>>>>> My original intypes entry was "Sk[]S”, should it just work if I change it to “m” ? I tried doing that and it’s complaining that it cannot find an opcode with matching argument types.
>>>>>> 
>>>>>> On 11 Aug 2014, at 13:06, Edward Costello  wrote:
>>>>>> 
>>>>>>> Ok, thanks
>>>>>>> Ed
>>>>>>> 
>>>>>>> On 11 Aug 2014, at 12:18, Victor Lazzarini  wrote:
>>>>>>> 
>>>>>>>> You will need to use a generic “all inputs” code: m
>>>>>>>> ========================
>>>>>>>> Dr Victor Lazzarini
>>>>>>>> Senior Lecturer
>>>>>>>> NUI Maynooth, Ireland
>>>>>>>> victor dot lazzarini at nuim dot ie
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 11 Aug 2014, at 11:14, jpff@cs.bath.ac.uk wrote:
>>>>>>>> 
>>>>>>>>> No such code exists
>>>>>>>>> 
>>>>>>>>> Quoting Edward Costello :
>>>>>>>>> 
>>>>>>>>>> Hi,
>>>>>>>>>> 
>>>>>>>>>> I am writing an opcode and I was just wondering what the magic
>>>>>>>>>> letters are for intypes for an opcode that takes a string then a
>>>>>>>>>> variable size of k-rate array and string pairs.
>>>>>>>>>> For example: SFilename, karray1, Sdataset1, karray2, Sdataset2,
>>>>>>>>>> karray3, Sdataset3,...
>>>>>>>>>> 
>>>>>>>>>> Thanks
>>>>>>>>>> Ed
>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>> _______________________________________________
>>>>>>>>>> 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
>>>>>>>> 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
>>>>>> 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
>>>> 
>>>> Dr Victor Lazzarini
>>>> Senior Lecturer
>>>> Dept. of Music
>>>> NUI Maynooth Ireland
>>>> tel.: +353 1 708 3545
>>>> Victor dot Lazzarini AT nuim dot ie
>>>> 
>>>> 
>>>> 
>>>> 
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> 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
>> 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

Hm, this could well be an issue with var-arg outputs and how to use it
in your code.  Check subinstr.  The data struct for it is in
H/insert.h (SUBINST).  It only has one MYFLT ar*[VARGMAX] for all
parameters, input and output.  I haven't had a chance to look, but my
guess is that the compiler lays out the out-args right after the
in-args in this case.  If so, you should be able to use OUTOCOUNT to
count how many output args were actually given, to index into where
the in-args start.

This makes sense, as to Csound, when it goes to set arg pointers, it's
just indexing into memory and using either the OENTRY's arg specifiers
as a guide, or using what args were given.

On Thu, Aug 14, 2014 at 2:29 PM, Victor Lazzarini
 wrote:
> I think there might be a bug lurking in here. I built and ran your opcode with the following line
>
>  i1, i2 opcodetest "hello", "hi", “ho"
>
> and this is what the debugger tells me:
>
> Process 97844 stopped
> * thread #1: tid = 0x9d9c55, 0x0000000106fe8f15 testop.dylib`opcode_init(csound=0x0000000101001200, self=0x000000010705edf0) + 101 at testop.cpp:19, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
>     frame #0: 0x0000000106fe8f15 testop.dylib`opcode_init(csound=0x0000000101001200, self=0x000000010705edf0) + 101 at testop.cpp:19
>    16       for (size_t i = 0; i < inputArgumentCount; ++i) {
>    17
>    18           STRINGDAT *currentString = (STRINGDAT *) self->inputArgs[i];
> -> 19           csound->Message(csound, "%s", currentString->data);
>    20       }
>    21
>    22       return OK;
> (lldb) print ((STRINGDAT *)self->outputArgs[2])->data
> (char *) $6 = 0x0000000100d7d730 "hello"
> (lldb) print ((STRINGDAT *)self->outputArgs[3])->data
> (char *) $7 = 0x0000000100d7d840 "hi"
> (lldb) print ((STRINGDAT *)self->outputArgs[4])->data
> (char *) $8 = 0x0000000100d7d950 “ho"
>
>
> see? all of the arguments have been passed in the outputArgs[] array. That does not seem right, it looks
> like a bug to me (in Csound).
>
> Regards
> ========================
> Dr Victor Lazzarini
> Senior Lecturer
> NUI Maynooth, Ireland
> victor dot lazzarini at nuim dot ie
>
>
>
>
> On 14 Aug 2014, at 18:33, Edward Costello  wrote:
>
>> This is a skeleton of the code I’m using, running this gives a segmentation fault. Am I not constructing the opcode correctly?
>>
>> #import 
>>
>> typedef struct _opcode
>> {
>>     OPDS h;
>>
>>     MYFLT *outputArgs[VARGMAX]; //arrays
>>     MYFLT *inputArgs[VARGMAX]; //strings
>>
>> } opcode;
>>
>> int opcode_init(CSOUND *csound, opcode *self)
>> {
>>     size_t inputArgumentCount = self->INOCOUNT;
>>
>>     for (size_t i = 0; i < inputArgumentCount; ++i) {
>>
>>         STRINGDAT *currentString = (STRINGDAT *) self->inputArgs[i];
>>         csound->Message(csound, "%s", currentString->data);
>>     }
>>
>>     return OK;
>> }
>>
>>
>> static OENTRY localops[] = {
>>
>>     {
>>         .opname = "opcodetest",
>>         .dsblksiz = sizeof(opcode),
>>         .thread = 1,
>>         .outypes = "*",
>>         .intypes = "*",
>>         .iopadr = (SUBR)opcode_init,
>>         .kopadr = NULL,
>>         .aopadr = NULL
>>     }
>> };
>>
>> LINKAGE
>>
>>
>>> On 14 Aug 2014, at 00:31, Edward Costello  wrote:
>>>
>>> Thanks the * seems to work, although I think there might be something wrong. When I use * for inputs and outputs where the inputs are all strings and the outputs all arrays, I am not able to get a pointer to my strings, they come out NULL, but if I remove the * for the outputs I can pick up the strings fine, is this a limitation?
>>>
>>>
>>>> On 12 Aug 2014, at 00:07, Steven Yi  wrote:
>>>>
>>>> I think in this case, maybe Ed could try using * which is a var-arg of
>>>> any type.  So maybe try using "S*".  I see that * is in the list of
>>>> characters accepted for var-arg in-args. (It looks like I added that
>>>> for xout...) I seem to remember a long email to the dev list about
>>>> using ? for an optional arg of any type, * for var-arg of any type,
>>>> and . for a mandatory arg of any type. This would have been about a
>>>> year and a half ago, as I probably wrote about it while we were in the
>>>> thick of getting 6.0.0 out the door.
>>>>
>>>> Ed, give that a go and see if that does the job. You could also check
>>>> in the init-function of your opcode the types at runtime to verify
>>>> that they are the kind you are expecting (k[], s, k[],s[], etc.).
>>>>
>>>> Victor: regarding m, I think we should hold off at the moment.  We
>>>> really should get rid of the single-letter args that are representing
>>>> var-args and optional-args, and replace it with a more advanced arg
>>>> notation, such as:
>>>>
>>>> "akk(43)i(0)k*"
>>>>
>>>> or something like that, where ak would be mandatory, k(43) would be
>>>> optional with default value 43, and the last k* would mean var-arg of
>>>> k-type.  (That syntax looks horrible, so let's not use it, but it
>>>> illustrates the idea.)
>>>>
>>>> Python has nice ways to define var-args and optional-args, i.e.:
>>>>
>>>> def myFunc(var1,var2, var3 = 440, *args):
>>>> doSomething()
>>>>
>>>> There's also some issues in dealing with the older notation, because
>>>> the internal system bubbled up to user-level through UDO args.  I did
>>>> have an idea that we could freeze the older syntax for instr and
>>>> opcode, but introduce new ones with Instr and Opcode (using
>>>> capitalized names).  That way, we could change the syntax of UDO's to
>>>> be something like:
>>>>
>>>> Opcode MyOpcode (kvar, avar, Sval, asigs[], ksigs[])
>>>> kval = 5
>>>> return kval
>>>> end
>>>>
>>>> where return would function similarly to xout.  Also, have named args
>>>> would allow easy interop with the type system. Sort of just
>>>> speculation though, maybe the syntax is a bit too different, I'm not
>>>> sure.
>>>>
>>>>
>>>> On Mon, Aug 11, 2014 at 4:24 PM, Victor Lazzarini
>>>>  wrote:
>>>>> I think "m" is only matching scalars not arrays. Should it be changed?
>>>>>
>>>>> Victor
>>>>> On 11 Aug 2014, at 21:08, Edward Costello wrote:
>>>>>
>>>>>> I tried “Sk[]Sm” and that fails, the parser won’t parse the csd with any string array pairs after the first ones.
>>>>>> As a test I just put in scalar k rate variables after the first array string pair and it worked though, does anyone know where I am going wrong?
>>>>>> Ed
>>>>>>
>>>>>> On 11 Aug 2014, at 19:39, Edward Costello  wrote:
>>>>>>
>>>>>>> My original intypes entry was "Sk[]S”, should it just work if I change it to “m” ? I tried doing that and it’s complaining that it cannot find an opcode with matching argument types.
>>>>>>>
>>>>>>> On 11 Aug 2014, at 13:06, Edward Costello  wrote:
>>>>>>>
>>>>>>>> Ok, thanks
>>>>>>>> Ed
>>>>>>>>
>>>>>>>> On 11 Aug 2014, at 12:18, Victor Lazzarini  wrote:
>>>>>>>>
>>>>>>>>> You will need to use a generic “all inputs” code: m
>>>>>>>>> ========================
>>>>>>>>> Dr Victor Lazzarini
>>>>>>>>> Senior Lecturer
>>>>>>>>> NUI Maynooth, Ireland
>>>>>>>>> victor dot lazzarini at nuim dot ie
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 11 Aug 2014, at 11:14, jpff@cs.bath.ac.uk wrote:
>>>>>>>>>
>>>>>>>>>> No such code exists
>>>>>>>>>>
>>>>>>>>>> Quoting Edward Costello :
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I am writing an opcode and I was just wondering what the magic
>>>>>>>>>>> letters are for intypes for an opcode that takes a string then a
>>>>>>>>>>> variable size of k-rate array and string pairs.
>>>>>>>>>>> For example: SFilename, karray1, Sdataset1, karray2, Sdataset2,
>>>>>>>>>>> karray3, Sdataset3,...
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> Ed
>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> 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
>>>>>>>>> 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
>>>>>>> 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
>>>>>
>>>>> Dr Victor Lazzarini
>>>>> Senior Lecturer
>>>>> Dept. of Music
>>>>> NUI Maynooth Ireland
>>>>> tel.: +353 1 708 3545
>>>>> Victor dot Lazzarini AT nuim dot ie
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> _______________________________________________
>>>>> 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
>>> 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
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sou

Interestingly, diskin has this for OENTRY 

{ "diskin",S(DISKIN2),0, 5,    "mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm",
    "Skooooooo”, ...

and
…
   OPDS    h;
    MYFLT   *aOut[DISKIN2_MAXCHN];

and

#define DISKIN2_MAXCHN  40   

========================
Dr Victor Lazzarini
Senior Lecturer
NUI Maynooth, Ireland
victor dot lazzarini at nuim dot ie




On 14 Aug 2014, at 19:57, Steven Yi  wrote:

> Hm, this could well be an issue with var-arg outputs and how to use it
> in your code.  Check subinstr.  The data struct for it is in
> H/insert.h (SUBINST).  It only has one MYFLT ar*[VARGMAX] for all
> parameters, input and output.  I haven't had a chance to look, but my
> guess is that the compiler lays out the out-args right after the
> in-args in this case.  If so, you should be able to use OUTOCOUNT to
> count how many output args were actually given, to index into where
> the in-args start.
> 
> This makes sense, as to Csound, when it goes to set arg pointers, it's
> just indexing into memory and using either the OENTRY's arg specifiers
> as a guide, or using what args were given.
> 
> On Thu, Aug 14, 2014 at 2:29 PM, Victor Lazzarini
>  wrote:
>> I think there might be a bug lurking in here. I built and ran your opcode with the following line
>> 
>> i1, i2 opcodetest "hello", "hi", “ho"
>> 
>> and this is what the debugger tells me:
>> 
>> Process 97844 stopped
>> * thread #1: tid = 0x9d9c55, 0x0000000106fe8f15 testop.dylib`opcode_init(csound=0x0000000101001200, self=0x000000010705edf0) + 101 at testop.cpp:19, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
>>    frame #0: 0x0000000106fe8f15 testop.dylib`opcode_init(csound=0x0000000101001200, self=0x000000010705edf0) + 101 at testop.cpp:19
>>   16       for (size_t i = 0; i < inputArgumentCount; ++i) {
>>   17
>>   18           STRINGDAT *currentString = (STRINGDAT *) self->inputArgs[i];
>> -> 19           csound->Message(csound, "%s", currentString->data);
>>   20       }
>>   21
>>   22       return OK;
>> (lldb) print ((STRINGDAT *)self->outputArgs[2])->data
>> (char *) $6 = 0x0000000100d7d730 "hello"
>> (lldb) print ((STRINGDAT *)self->outputArgs[3])->data
>> (char *) $7 = 0x0000000100d7d840 "hi"
>> (lldb) print ((STRINGDAT *)self->outputArgs[4])->data
>> (char *) $8 = 0x0000000100d7d950 “ho"
>> 
>> 
>> see? all of the arguments have been passed in the outputArgs[] array. That does not seem right, it looks
>> like a bug to me (in Csound).
>> 
>> Regards
>> ========================
>> Dr Victor Lazzarini
>> Senior Lecturer
>> NUI Maynooth, Ireland
>> victor dot lazzarini at nuim dot ie
>> 
>> 
>> 
>> 
>> On 14 Aug 2014, at 18:33, Edward Costello  wrote:
>> 
>>> This is a skeleton of the code I’m using, running this gives a segmentation fault. Am I not constructing the opcode correctly?
>>> 
>>> #import 
>>> 
>>> typedef struct _opcode
>>> {
>>>    OPDS h;
>>> 
>>>    MYFLT *outputArgs[VARGMAX]; //arrays
>>>    MYFLT *inputArgs[VARGMAX]; //strings
>>> 
>>> } opcode;
>>> 
>>> int opcode_init(CSOUND *csound, opcode *self)
>>> {
>>>    size_t inputArgumentCount = self->INOCOUNT;
>>> 
>>>    for (size_t i = 0; i < inputArgumentCount; ++i) {
>>> 
>>>        STRINGDAT *currentString = (STRINGDAT *) self->inputArgs[i];
>>>        csound->Message(csound, "%s", currentString->data);
>>>    }
>>> 
>>>    return OK;
>>> }
>>> 
>>> 
>>> static OENTRY localops[] = {
>>> 
>>>    {
>>>        .opname = "opcodetest",
>>>        .dsblksiz = sizeof(opcode),
>>>        .thread = 1,
>>>        .outypes = "*",
>>>        .intypes = "*",
>>>        .iopadr = (SUBR)opcode_init,
>>>        .kopadr = NULL,
>>>        .aopadr = NULL
>>>    }
>>> };
>>> 
>>> LINKAGE
>>> 
>>> 
>>>> On 14 Aug 2014, at 00:31, Edward Costello  wrote:
>>>> 
>>>> Thanks the * seems to work, although I think there might be something wrong. When I use * for inputs and outputs where the inputs are all strings and the outputs all arrays, I am not able to get a pointer to my strings, they come out NULL, but if I remove the * for the outputs I can pick up the strings fine, is this a limitation?
>>>> 
>>>> 
>>>>> On 12 Aug 2014, at 00:07, Steven Yi  wrote:
>>>>> 
>>>>> I think in this case, maybe Ed could try using * which is a var-arg of
>>>>> any type.  So maybe try using "S*".  I see that * is in the list of
>>>>> characters accepted for var-arg in-args. (It looks like I added that
>>>>> for xout...) I seem to remember a long email to the dev list about
>>>>> using ? for an optional arg of any type, * for var-arg of any type,
>>>>> and . for a mandatory arg of any type. This would have been about a
>>>>> year and a half ago, as I probably wrote about it while we were in the
>>>>> thick of getting 6.0.0 out the door.
>>>>> 
>>>>> Ed, give that a go and see if that does the job. You could also check
>>>>> in the init-function of your opcode the types at runtime to verify
>>>>> that they are the kind you are expecting (k[], s, k[],s[], etc.).
>>>>> 
>>>>> Victor: regarding m, I think we should hold off at the moment.  We
>>>>> really should get rid of the single-letter args that are representing
>>>>> var-args and optional-args, and replace it with a more advanced arg
>>>>> notation, such as:
>>>>> 
>>>>> "akk(43)i(0)k*"
>>>>> 
>>>>> or something like that, where ak would be mandatory, k(43) would be
>>>>> optional with default value 43, and the last k* would mean var-arg of
>>>>> k-type.  (That syntax looks horrible, so let's not use it, but it
>>>>> illustrates the idea.)
>>>>> 
>>>>> Python has nice ways to define var-args and optional-args, i.e.:
>>>>> 
>>>>> def myFunc(var1,var2, var3 = 440, *args):
>>>>> doSomething()
>>>>> 
>>>>> There's also some issues in dealing with the older notation, because
>>>>> the internal system bubbled up to user-level through UDO args.  I did
>>>>> have an idea that we could freeze the older syntax for instr and
>>>>> opcode, but introduce new ones with Instr and Opcode (using
>>>>> capitalized names).  That way, we could change the syntax of UDO's to
>>>>> be something like:
>>>>> 
>>>>> Opcode MyOpcode (kvar, avar, Sval, asigs[], ksigs[])
>>>>> kval = 5
>>>>> return kval
>>>>> end
>>>>> 
>>>>> where return would function similarly to xout.  Also, have named args
>>>>> would allow easy interop with the type system. Sort of just
>>>>> speculation though, maybe the syntax is a bit too different, I'm not
>>>>> sure.
>>>>> 
>>>>> 
>>>>> On Mon, Aug 11, 2014 at 4:24 PM, Victor Lazzarini
>>>>>  wrote:
>>>>>> I think "m" is only matching scalars not arrays. Should it be changed?
>>>>>> 
>>>>>> Victor
>>>>>> On 11 Aug 2014, at 21:08, Edward Costello wrote:
>>>>>> 
>>>>>>> I tried “Sk[]Sm” and that fails, the parser won’t parse the csd with any string array pairs after the first ones.
>>>>>>> As a test I just put in scalar k rate variables after the first array string pair and it worked though, does anyone know where I am going wrong?
>>>>>>> Ed
>>>>>>> 
>>>>>>> On 11 Aug 2014, at 19:39, Edward Costello  wrote:
>>>>>>> 
>>>>>>>> My original intypes entry was "Sk[]S”, should it just work if I change it to “m” ? I tried doing that and it’s complaining that it cannot find an opcode with matching argument types.
>>>>>>>> 
>>>>>>>> On 11 Aug 2014, at 13:06, Edward Costello  wrote:
>>>>>>>> 
>>>>>>>>> Ok, thanks
>>>>>>>>> Ed
>>>>>>>>> 
>>>>>>>>> On 11 Aug 2014, at 12:18, Victor Lazzarini  wrote:
>>>>>>>>> 
>>>>>>>>>> You will need to use a generic “all inputs” code: m
>>>>>>>>>> ========================
>>>>>>>>>> Dr Victor Lazzarini
>>>>>>>>>> Senior Lecturer
>>>>>>>>>> NUI Maynooth, Ireland
>>>>>>>>>> victor dot lazzarini at nuim dot ie
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On 11 Aug 2014, at 11:14, jpff@cs.bath.ac.uk wrote:
>>>>>>>>>> 
>>>>>>>>>>> No such code exists
>>>>>>>>>>> 
>>>>>>>>>>> Quoting Edward Costello :
>>>>>>>>>>> 
>>>>>>>>>>>> Hi,
>>>>>>>>>>>> 
>>>>>>>>>>>> I am writing an opcode and I was just wondering what the magic
>>>>>>>>>>>> letters are for intypes for an opcode that takes a string then a
>>>>>>>>>>>> variable size of k-rate array and string pairs.
>>>>>>>>>>>> For example: SFilename, karray1, Sdataset1, karray2, Sdataset2,
>>>>>>>>>>>> karray3, Sdataset3,...
>>>>>>>>>>>> 
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Ed
>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> 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
>>>>>>>>>> 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
>>>>>>>> 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
>>>>>> 
>>>>>> Dr Victor Lazzarini
>>>>>> Senior Lecturer
>>>>>> Dept. of Music
>>>>>> NUI Maynooth Ireland
>>>>>> tel.: +353 1 708 3545
>>>>>> Victor dot Lazzarini AT nuim dot ie
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> ------------------------------------------------------------------------------
>>>>>> _______________________________________________
>>>>>> 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
>>>> 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
>> 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

Yeah, the solution in this case is to use just a single MYFLT array for all arguments. In case anyone is interested I just wrote opcodes for reading and writing arrays to hdf5 files. This is handy as they can be read by matlab and a few other things like R and python. The read opcode can read multiple data sets from a single file at i-time, and the write opcode can write multiple datasets at a time to a single file at k-rate.

Ed


> On 14 Aug 2014, at 21:15, Victor Lazzarini  wrote:
> 
> Interestingly, diskin has this for OENTRY 
> 
> { "diskin",S(DISKIN2),0, 5,    "mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm",
>    "Skooooooo”, ...
> 
> and
> …
>   OPDS    h;
>    MYFLT   *aOut[DISKIN2_MAXCHN];
> 
> and
> 
> #define DISKIN2_MAXCHN  40   
> 
> ========================
> Dr Victor Lazzarini
> Senior Lecturer
> NUI Maynooth, Ireland
> victor dot lazzarini at nuim dot ie
> 
> 
> 
> 
> On 14 Aug 2014, at 19:57, Steven Yi  wrote:
> 
>> Hm, this could well be an issue with var-arg outputs and how to use it
>> in your code.  Check subinstr.  The data struct for it is in
>> H/insert.h (SUBINST).  It only has one MYFLT ar*[VARGMAX] for all
>> parameters, input and output.  I haven't had a chance to look, but my
>> guess is that the compiler lays out the out-args right after the
>> in-args in this case.  If so, you should be able to use OUTOCOUNT to
>> count how many output args were actually given, to index into where
>> the in-args start.
>> 
>> This makes sense, as to Csound, when it goes to set arg pointers, it's
>> just indexing into memory and using either the OENTRY's arg specifiers
>> as a guide, or using what args were given.
>> 
>> On Thu, Aug 14, 2014 at 2:29 PM, Victor Lazzarini
>>  wrote:
>>> I think there might be a bug lurking in here. I built and ran your opcode with the following line
>>> 
>>> i1, i2 opcodetest "hello", "hi", “ho"
>>> 
>>> and this is what the debugger tells me:
>>> 
>>> Process 97844 stopped
>>> * thread #1: tid = 0x9d9c55, 0x0000000106fe8f15 testop.dylib`opcode_init(csound=0x0000000101001200, self=0x000000010705edf0) + 101 at testop.cpp:19, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
>>>   frame #0: 0x0000000106fe8f15 testop.dylib`opcode_init(csound=0x0000000101001200, self=0x000000010705edf0) + 101 at testop.cpp:19
>>>  16       for (size_t i = 0; i < inputArgumentCount; ++i) {
>>>  17
>>>  18           STRINGDAT *currentString = (STRINGDAT *) self->inputArgs[i];
>>> -> 19           csound->Message(csound, "%s", currentString->data);
>>>  20       }
>>>  21
>>>  22       return OK;
>>> (lldb) print ((STRINGDAT *)self->outputArgs[2])->data
>>> (char *) $6 = 0x0000000100d7d730 "hello"
>>> (lldb) print ((STRINGDAT *)self->outputArgs[3])->data
>>> (char *) $7 = 0x0000000100d7d840 "hi"
>>> (lldb) print ((STRINGDAT *)self->outputArgs[4])->data
>>> (char *) $8 = 0x0000000100d7d950 “ho"
>>> 
>>> 
>>> see? all of the arguments have been passed in the outputArgs[] array. That does not seem right, it looks
>>> like a bug to me (in Csound).
>>> 
>>> Regards
>>> ========================
>>> Dr Victor Lazzarini
>>> Senior Lecturer
>>> NUI Maynooth, Ireland
>>> victor dot lazzarini at nuim dot ie
>>> 
>>> 
>>> 
>>> 
>>> On 14 Aug 2014, at 18:33, Edward Costello  wrote:
>>> 
>>>> This is a skeleton of the code I’m using, running this gives a segmentation fault. Am I not constructing the opcode correctly?
>>>> 
>>>> #import 
>>>> 
>>>> typedef struct _opcode
>>>> {
>>>>   OPDS h;
>>>> 
>>>>   MYFLT *outputArgs[VARGMAX]; //arrays
>>>>   MYFLT *inputArgs[VARGMAX]; //strings
>>>> 
>>>> } opcode;
>>>> 
>>>> int opcode_init(CSOUND *csound, opcode *self)
>>>> {
>>>>   size_t inputArgumentCount = self->INOCOUNT;
>>>> 
>>>>   for (size_t i = 0; i < inputArgumentCount; ++i) {
>>>> 
>>>>       STRINGDAT *currentString = (STRINGDAT *) self->inputArgs[i];
>>>>       csound->Message(csound, "%s", currentString->data);
>>>>   }
>>>> 
>>>>   return OK;
>>>> }
>>>> 
>>>> 
>>>> static OENTRY localops[] = {
>>>> 
>>>>   {
>>>>       .opname = "opcodetest",
>>>>       .dsblksiz = sizeof(opcode),
>>>>       .thread = 1,
>>>>       .outypes = "*",
>>>>       .intypes = "*",
>>>>       .iopadr = (SUBR)opcode_init,
>>>>       .kopadr = NULL,
>>>>       .aopadr = NULL
>>>>   }
>>>> };
>>>> 
>>>> LINKAGE
>>>> 
>>>> 
>>>>> On 14 Aug 2014, at 00:31, Edward Costello  wrote:
>>>>> 
>>>>> Thanks the * seems to work, although I think there might be something wrong. When I use * for inputs and outputs where the inputs are all strings and the outputs all arrays, I am not able to get a pointer to my strings, they come out NULL, but if I remove the * for the outputs I can pick up the strings fine, is this a limitation?
>>>>> 
>>>>> 
>>>>>> On 12 Aug 2014, at 00:07, Steven Yi  wrote:
>>>>>> 
>>>>>> I think in this case, maybe Ed could try using * which is a var-arg of
>>>>>> any type.  So maybe try using "S*".  I see that * is in the list of
>>>>>> characters accepted for var-arg in-args. (It looks like I added that
>>>>>> for xout...) I seem to remember a long email to the dev list about
>>>>>> using ? for an optional arg of any type, * for var-arg of any type,
>>>>>> and . for a mandatory arg of any type. This would have been about a
>>>>>> year and a half ago, as I probably wrote about it while we were in the
>>>>>> thick of getting 6.0.0 out the door.
>>>>>> 
>>>>>> Ed, give that a go and see if that does the job. You could also check
>>>>>> in the init-function of your opcode the types at runtime to verify
>>>>>> that they are the kind you are expecting (k[], s, k[],s[], etc.).
>>>>>> 
>>>>>> Victor: regarding m, I think we should hold off at the moment.  We
>>>>>> really should get rid of the single-letter args that are representing
>>>>>> var-args and optional-args, and replace it with a more advanced arg
>>>>>> notation, such as:
>>>>>> 
>>>>>> "akk(43)i(0)k*"
>>>>>> 
>>>>>> or something like that, where ak would be mandatory, k(43) would be
>>>>>> optional with default value 43, and the last k* would mean var-arg of
>>>>>> k-type.  (That syntax looks horrible, so let's not use it, but it
>>>>>> illustrates the idea.)
>>>>>> 
>>>>>> Python has nice ways to define var-args and optional-args, i.e.:
>>>>>> 
>>>>>> def myFunc(var1,var2, var3 = 440, *args):
>>>>>> doSomething()
>>>>>> 
>>>>>> There's also some issues in dealing with the older notation, because
>>>>>> the internal system bubbled up to user-level through UDO args.  I did
>>>>>> have an idea that we could freeze the older syntax for instr and
>>>>>> opcode, but introduce new ones with Instr and Opcode (using
>>>>>> capitalized names).  That way, we could change the syntax of UDO's to
>>>>>> be something like:
>>>>>> 
>>>>>> Opcode MyOpcode (kvar, avar, Sval, asigs[], ksigs[])
>>>>>> kval = 5
>>>>>> return kval
>>>>>> end
>>>>>> 
>>>>>> where return would function similarly to xout.  Also, have named args
>>>>>> would allow easy interop with the type system. Sort of just
>>>>>> speculation though, maybe the syntax is a bit too different, I'm not
>>>>>> sure.
>>>>>> 
>>>>>> 
>>>>>> On Mon, Aug 11, 2014 at 4:24 PM, Victor Lazzarini
>>>>>>  wrote:
>>>>>>> I think "m" is only matching scalars not arrays. Should it be changed?
>>>>>>> 
>>>>>>> Victor
>>>>>>> On 11 Aug 2014, at 21:08, Edward Costello wrote:
>>>>>>> 
>>>>>>>> I tried “Sk[]Sm” and that fails, the parser won’t parse the csd with any string array pairs after the first ones.
>>>>>>>> As a test I just put in scalar k rate variables after the first array string pair and it worked though, does anyone know where I am going wrong?
>>>>>>>> Ed
>>>>>>>> 
>>>>>>>> On 11 Aug 2014, at 19:39, Edward Costello  wrote:
>>>>>>>> 
>>>>>>>>> My original intypes entry was "Sk[]S”, should it just work if I change it to “m” ? I tried doing that and it’s complaining that it cannot find an opcode with matching argument types.
>>>>>>>>> 
>>>>>>>>> On 11 Aug 2014, at 13:06, Edward Costello  wrote:
>>>>>>>>> 
>>>>>>>>>> Ok, thanks
>>>>>>>>>> Ed
>>>>>>>>>> 
>>>>>>>>>> On 11 Aug 2014, at 12:18, Victor Lazzarini  wrote:
>>>>>>>>>> 
>>>>>>>>>>> You will need to use a generic “all inputs” code: m
>>>>>>>>>>> ========================
>>>>>>>>>>> Dr Victor Lazzarini
>>>>>>>>>>> Senior Lecturer
>>>>>>>>>>> NUI Maynooth, Ireland
>>>>>>>>>>> victor dot lazzarini at nuim dot ie
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On 11 Aug 2014, at 11:14, jpff@cs.bath.ac.uk wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> No such code exists
>>>>>>>>>>>> 
>>>>>>>>>>>> Quoting Edward Costello :
>>>>>>>>>>>> 
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I am writing an opcode and I was just wondering what the magic
>>>>>>>>>>>>> letters are for intypes for an opcode that takes a string then a
>>>>>>>>>>>>> variable size of k-rate array and string pairs.
>>>>>>>>>>>>> For example: SFilename, karray1, Sdataset1, karray2, Sdataset2,
>>>>>>>>>>>>> karray3, Sdataset3,...
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>> Ed
>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> 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
>>>>>>>>>>> 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
>>>>>>>>> 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
>>>>>>> 
>>>>>>> Dr Victor Lazzarini
>>>>>>> Senior Lecturer
>>>>>>> Dept. of Music
>>>>>>> NUI Maynooth Ireland
>>>>>>> tel.: +353 1 708 3545
>>>>>>> Victor dot Lazzarini AT nuim dot ie
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>> 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
>>> 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
> https://lists.sourceforge.net/lists/listinfo/csound-devel


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

Can you contribute these to the Csound sources (+ manual)?
========================
Dr Victor Lazzarini
Senior Lecturer
NUI Maynooth, Ireland
victor dot lazzarini at nuim dot ie




On 14 Aug 2014, at 20:57, Edward Costello  wrote:

> Yeah, the solution in this case is to use just a single MYFLT array for all arguments. In case anyone is interested I just wrote opcodes for reading and writing arrays to hdf5 files. This is handy as they can be read by matlab and a few other things like R and python. The read opcode can read multiple data sets from a single file at i-time, and the write opcode can write multiple datasets at a time to a single file at k-rate.
> 
> Ed
> 
> 
>> On 14 Aug 2014, at 21:15, Victor Lazzarini  wrote:
>> 
>> Interestingly, diskin has this for OENTRY 
>> 
>> { "diskin",S(DISKIN2),0, 5,    "mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm",
>>   "Skooooooo”, ...
>> 
>> and
>> …
>>  OPDS    h;
>>   MYFLT   *aOut[DISKIN2_MAXCHN];
>> 
>> and
>> 
>> #define DISKIN2_MAXCHN  40   
>> 
>> ========================
>> Dr Victor Lazzarini
>> Senior Lecturer
>> NUI Maynooth, Ireland
>> victor dot lazzarini at nuim dot ie
>> 
>> 
>> 
>> 
>> On 14 Aug 2014, at 19:57, Steven Yi  wrote:
>> 
>>> Hm, this could well be an issue with var-arg outputs and how to use it
>>> in your code.  Check subinstr.  The data struct for it is in
>>> H/insert.h (SUBINST).  It only has one MYFLT ar*[VARGMAX] for all
>>> parameters, input and output.  I haven't had a chance to look, but my
>>> guess is that the compiler lays out the out-args right after the
>>> in-args in this case.  If so, you should be able to use OUTOCOUNT to
>>> count how many output args were actually given, to index into where
>>> the in-args start.
>>> 
>>> This makes sense, as to Csound, when it goes to set arg pointers, it's
>>> just indexing into memory and using either the OENTRY's arg specifiers
>>> as a guide, or using what args were given.
>>> 
>>> On Thu, Aug 14, 2014 at 2:29 PM, Victor Lazzarini
>>>  wrote:
>>>> I think there might be a bug lurking in here. I built and ran your opcode with the following line
>>>> 
>>>> i1, i2 opcodetest "hello", "hi", “ho"
>>>> 
>>>> and this is what the debugger tells me:
>>>> 
>>>> Process 97844 stopped
>>>> * thread #1: tid = 0x9d9c55, 0x0000000106fe8f15 testop.dylib`opcode_init(csound=0x0000000101001200, self=0x000000010705edf0) + 101 at testop.cpp:19, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
>>>>  frame #0: 0x0000000106fe8f15 testop.dylib`opcode_init(csound=0x0000000101001200, self=0x000000010705edf0) + 101 at testop.cpp:19
>>>> 16       for (size_t i = 0; i < inputArgumentCount; ++i) {
>>>> 17
>>>> 18           STRINGDAT *currentString = (STRINGDAT *) self->inputArgs[i];
>>>> -> 19           csound->Message(csound, "%s", currentString->data);
>>>> 20       }
>>>> 21
>>>> 22       return OK;
>>>> (lldb) print ((STRINGDAT *)self->outputArgs[2])->data
>>>> (char *) $6 = 0x0000000100d7d730 "hello"
>>>> (lldb) print ((STRINGDAT *)self->outputArgs[3])->data
>>>> (char *) $7 = 0x0000000100d7d840 "hi"
>>>> (lldb) print ((STRINGDAT *)self->outputArgs[4])->data
>>>> (char *) $8 = 0x0000000100d7d950 “ho"
>>>> 
>>>> 
>>>> see? all of the arguments have been passed in the outputArgs[] array. That does not seem right, it looks
>>>> like a bug to me (in Csound).
>>>> 
>>>> Regards
>>>> ========================
>>>> Dr Victor Lazzarini
>>>> Senior Lecturer
>>>> NUI Maynooth, Ireland
>>>> victor dot lazzarini at nuim dot ie
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On 14 Aug 2014, at 18:33, Edward Costello  wrote:
>>>> 
>>>>> This is a skeleton of the code I’m using, running this gives a segmentation fault. Am I not constructing the opcode correctly?
>>>>> 
>>>>> #import 
>>>>> 
>>>>> typedef struct _opcode
>>>>> {
>>>>>  OPDS h;
>>>>> 
>>>>>  MYFLT *outputArgs[VARGMAX]; //arrays
>>>>>  MYFLT *inputArgs[VARGMAX]; //strings
>>>>> 
>>>>> } opcode;
>>>>> 
>>>>> int opcode_init(CSOUND *csound, opcode *self)
>>>>> {
>>>>>  size_t inputArgumentCount = self->INOCOUNT;
>>>>> 
>>>>>  for (size_t i = 0; i < inputArgumentCount; ++i) {
>>>>> 
>>>>>      STRINGDAT *currentString = (STRINGDAT *) self->inputArgs[i];
>>>>>      csound->Message(csound, "%s", currentString->data);
>>>>>  }
>>>>> 
>>>>>  return OK;
>>>>> }
>>>>> 
>>>>> 
>>>>> static OENTRY localops[] = {
>>>>> 
>>>>>  {
>>>>>      .opname = "opcodetest",
>>>>>      .dsblksiz = sizeof(opcode),
>>>>>      .thread = 1,
>>>>>      .outypes = "*",
>>>>>      .intypes = "*",
>>>>>      .iopadr = (SUBR)opcode_init,
>>>>>      .kopadr = NULL,
>>>>>      .aopadr = NULL
>>>>>  }
>>>>> };
>>>>> 
>>>>> LINKAGE
>>>>> 
>>>>> 
>>>>>> On 14 Aug 2014, at 00:31, Edward Costello  wrote:
>>>>>> 
>>>>>> Thanks the * seems to work, although I think there might be something wrong. When I use * for inputs and outputs where the inputs are all strings and the outputs all arrays, I am not able to get a pointer to my strings, they come out NULL, but if I remove the * for the outputs I can pick up the strings fine, is this a limitation?
>>>>>> 
>>>>>> 
>>>>>>> On 12 Aug 2014, at 00:07, Steven Yi  wrote:
>>>>>>> 
>>>>>>> I think in this case, maybe Ed could try using * which is a var-arg of
>>>>>>> any type.  So maybe try using "S*".  I see that * is in the list of
>>>>>>> characters accepted for var-arg in-args. (It looks like I added that
>>>>>>> for xout...) I seem to remember a long email to the dev list about
>>>>>>> using ? for an optional arg of any type, * for var-arg of any type,
>>>>>>> and . for a mandatory arg of any type. This would have been about a
>>>>>>> year and a half ago, as I probably wrote about it while we were in the
>>>>>>> thick of getting 6.0.0 out the door.
>>>>>>> 
>>>>>>> Ed, give that a go and see if that does the job. You could also check
>>>>>>> in the init-function of your opcode the types at runtime to verify
>>>>>>> that they are the kind you are expecting (k[], s, k[],s[], etc.).
>>>>>>> 
>>>>>>> Victor: regarding m, I think we should hold off at the moment.  We
>>>>>>> really should get rid of the single-letter args that are representing
>>>>>>> var-args and optional-args, and replace it with a more advanced arg
>>>>>>> notation, such as:
>>>>>>> 
>>>>>>> "akk(43)i(0)k*"
>>>>>>> 
>>>>>>> or something like that, where ak would be mandatory, k(43) would be
>>>>>>> optional with default value 43, and the last k* would mean var-arg of
>>>>>>> k-type.  (That syntax looks horrible, so let's not use it, but it
>>>>>>> illustrates the idea.)
>>>>>>> 
>>>>>>> Python has nice ways to define var-args and optional-args, i.e.:
>>>>>>> 
>>>>>>> def myFunc(var1,var2, var3 = 440, *args):
>>>>>>> doSomething()
>>>>>>> 
>>>>>>> There's also some issues in dealing with the older notation, because
>>>>>>> the internal system bubbled up to user-level through UDO args.  I did
>>>>>>> have an idea that we could freeze the older syntax for instr and
>>>>>>> opcode, but introduce new ones with Instr and Opcode (using
>>>>>>> capitalized names).  That way, we could change the syntax of UDO's to
>>>>>>> be something like:
>>>>>>> 
>>>>>>> Opcode MyOpcode (kvar, avar, Sval, asigs[], ksigs[])
>>>>>>> kval = 5
>>>>>>> return kval
>>>>>>> end
>>>>>>> 
>>>>>>> where return would function similarly to xout.  Also, have named args
>>>>>>> would allow easy interop with the type system. Sort of just
>>>>>>> speculation though, maybe the syntax is a bit too different, I'm not
>>>>>>> sure.
>>>>>>> 
>>>>>>> 
>>>>>>> On Mon, Aug 11, 2014 at 4:24 PM, Victor Lazzarini
>>>>>>>  wrote:
>>>>>>>> I think "m" is only matching scalars not arrays. Should it be changed?
>>>>>>>> 
>>>>>>>> Victor
>>>>>>>> On 11 Aug 2014, at 21:08, Edward Costello wrote:
>>>>>>>> 
>>>>>>>>> I tried “Sk[]Sm” and that fails, the parser won’t parse the csd with any string array pairs after the first ones.
>>>>>>>>> As a test I just put in scalar k rate variables after the first array string pair and it worked though, does anyone know where I am going wrong?
>>>>>>>>> Ed
>>>>>>>>> 
>>>>>>>>> On 11 Aug 2014, at 19:39, Edward Costello  wrote:
>>>>>>>>> 
>>>>>>>>>> My original intypes entry was "Sk[]S”, should it just work if I change it to “m” ? I tried doing that and it’s complaining that it cannot find an opcode with matching argument types.
>>>>>>>>>> 
>>>>>>>>>> On 11 Aug 2014, at 13:06, Edward Costello  wrote:
>>>>>>>>>> 
>>>>>>>>>>> Ok, thanks
>>>>>>>>>>> Ed
>>>>>>>>>>> 
>>>>>>>>>>> On 11 Aug 2014, at 12:18, Victor Lazzarini  wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> You will need to use a generic “all inputs” code: m
>>>>>>>>>>>> ========================
>>>>>>>>>>>> Dr Victor Lazzarini
>>>>>>>>>>>> Senior Lecturer
>>>>>>>>>>>> NUI Maynooth, Ireland
>>>>>>>>>>>> victor dot lazzarini at nuim dot ie
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> On 11 Aug 2014, at 11:14, jpff@cs.bath.ac.uk wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> No such code exists
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Quoting Edward Costello :
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I am writing an opcode and I was just wondering what the magic
>>>>>>>>>>>>>> letters are for intypes for an opcode that takes a string then a
>>>>>>>>>>>>>> variable size of k-rate array and string pairs.
>>>>>>>>>>>>>> For example: SFilename, karray1, Sdataset1, karray2, Sdataset2,
>>>>>>>>>>>>>> karray3, Sdataset3,...
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>> Ed
>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> 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
>>>>>>>>>>>> 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
>>>>>>>>>> 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
>>>>>>>> 
>>>>>>>> Dr Victor Lazzarini
>>>>>>>> Senior Lecturer
>>>>>>>> Dept. of Music
>>>>>>>> NUI Maynooth Ireland
>>>>>>>> tel.: +353 1 708 3545
>>>>>>>> Victor dot Lazzarini AT nuim dot ie
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>> 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
>>>> 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
>> 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

Yeah sure, whats needed, a license on the sources and a manual page? 

> On 14 Aug 2014, at 22:11, Victor Lazzarini  wrote:
> 
> Can you contribute these to the Csound sources (+ manual)?
> ========================
> Dr Victor Lazzarini
> Senior Lecturer
> NUI Maynooth, Ireland
> victor dot lazzarini at nuim dot ie
> 
> 
> 
> 
> On 14 Aug 2014, at 20:57, Edward Costello  wrote:
> 
>> Yeah, the solution in this case is to use just a single MYFLT array for all arguments. In case anyone is interested I just wrote opcodes for reading and writing arrays to hdf5 files. This is handy as they can be read by matlab and a few other things like R and python. The read opcode can read multiple data sets from a single file at i-time, and the write opcode can write multiple datasets at a time to a single file at k-rate.
>> 
>> Ed
>> 
>> 
>>> On 14 Aug 2014, at 21:15, Victor Lazzarini  wrote:
>>> 
>>> Interestingly, diskin has this for OENTRY 
>>> 
>>> { "diskin",S(DISKIN2),0, 5,    "mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm",
>>>  "Skooooooo”, ...
>>> 
>>> and
>>> …
>>> OPDS    h;
>>>  MYFLT   *aOut[DISKIN2_MAXCHN];
>>> 
>>> and
>>> 
>>> #define DISKIN2_MAXCHN  40   
>>> 
>>> ========================
>>> Dr Victor Lazzarini
>>> Senior Lecturer
>>> NUI Maynooth, Ireland
>>> victor dot lazzarini at nuim dot ie
>>> 
>>> 
>>> 
>>> 
>>> On 14 Aug 2014, at 19:57, Steven Yi  wrote:
>>> 
>>>> Hm, this could well be an issue with var-arg outputs and how to use it
>>>> in your code.  Check subinstr.  The data struct for it is in
>>>> H/insert.h (SUBINST).  It only has one MYFLT ar*[VARGMAX] for all
>>>> parameters, input and output.  I haven't had a chance to look, but my
>>>> guess is that the compiler lays out the out-args right after the
>>>> in-args in this case.  If so, you should be able to use OUTOCOUNT to
>>>> count how many output args were actually given, to index into where
>>>> the in-args start.
>>>> 
>>>> This makes sense, as to Csound, when it goes to set arg pointers, it's
>>>> just indexing into memory and using either the OENTRY's arg specifiers
>>>> as a guide, or using what args were given.
>>>> 
>>>> On Thu, Aug 14, 2014 at 2:29 PM, Victor Lazzarini
>>>>  wrote:
>>>>> I think there might be a bug lurking in here. I built and ran your opcode with the following line
>>>>> 
>>>>> i1, i2 opcodetest "hello", "hi", “ho"
>>>>> 
>>>>> and this is what the debugger tells me:
>>>>> 
>>>>> Process 97844 stopped
>>>>> * thread #1: tid = 0x9d9c55, 0x0000000106fe8f15 testop.dylib`opcode_init(csound=0x0000000101001200, self=0x000000010705edf0) + 101 at testop.cpp:19, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
>>>>> frame #0: 0x0000000106fe8f15 testop.dylib`opcode_init(csound=0x0000000101001200, self=0x000000010705edf0) + 101 at testop.cpp:19
>>>>> 16       for (size_t i = 0; i < inputArgumentCount; ++i) {
>>>>> 17
>>>>> 18           STRINGDAT *currentString = (STRINGDAT *) self->inputArgs[i];
>>>>> -> 19           csound->Message(csound, "%s", currentString->data);
>>>>> 20       }
>>>>> 21
>>>>> 22       return OK;
>>>>> (lldb) print ((STRINGDAT *)self->outputArgs[2])->data
>>>>> (char *) $6 = 0x0000000100d7d730 "hello"
>>>>> (lldb) print ((STRINGDAT *)self->outputArgs[3])->data
>>>>> (char *) $7 = 0x0000000100d7d840 "hi"
>>>>> (lldb) print ((STRINGDAT *)self->outputArgs[4])->data
>>>>> (char *) $8 = 0x0000000100d7d950 “ho"
>>>>> 
>>>>> 
>>>>> see? all of the arguments have been passed in the outputArgs[] array. That does not seem right, it looks
>>>>> like a bug to me (in Csound).
>>>>> 
>>>>> Regards
>>>>> ========================
>>>>> Dr Victor Lazzarini
>>>>> Senior Lecturer
>>>>> NUI Maynooth, Ireland
>>>>> victor dot lazzarini at nuim dot ie
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On 14 Aug 2014, at 18:33, Edward Costello  wrote:
>>>>> 
>>>>>> This is a skeleton of the code I’m using, running this gives a segmentation fault. Am I not constructing the opcode correctly?
>>>>>> 
>>>>>> #import 
>>>>>> 
>>>>>> typedef struct _opcode
>>>>>> {
>>>>>> OPDS h;
>>>>>> 
>>>>>> MYFLT *outputArgs[VARGMAX]; //arrays
>>>>>> MYFLT *inputArgs[VARGMAX]; //strings
>>>>>> 
>>>>>> } opcode;
>>>>>> 
>>>>>> int opcode_init(CSOUND *csound, opcode *self)
>>>>>> {
>>>>>> size_t inputArgumentCount = self->INOCOUNT;
>>>>>> 
>>>>>> for (size_t i = 0; i < inputArgumentCount; ++i) {
>>>>>> 
>>>>>>     STRINGDAT *currentString = (STRINGDAT *) self->inputArgs[i];
>>>>>>     csound->Message(csound, "%s", currentString->data);
>>>>>> }
>>>>>> 
>>>>>> return OK;
>>>>>> }
>>>>>> 
>>>>>> 
>>>>>> static OENTRY localops[] = {
>>>>>> 
>>>>>> {
>>>>>>     .opname = "opcodetest",
>>>>>>     .dsblksiz = sizeof(opcode),
>>>>>>     .thread = 1,
>>>>>>     .outypes = "*",
>>>>>>     .intypes = "*",
>>>>>>     .iopadr = (SUBR)opcode_init,
>>>>>>     .kopadr = NULL,
>>>>>>     .aopadr = NULL
>>>>>> }
>>>>>> };
>>>>>> 
>>>>>> LINKAGE
>>>>>> 
>>>>>> 
>>>>>>> On 14 Aug 2014, at 00:31, Edward Costello  wrote:
>>>>>>> 
>>>>>>> Thanks the * seems to work, although I think there might be something wrong. When I use * for inputs and outputs where the inputs are all strings and the outputs all arrays, I am not able to get a pointer to my strings, they come out NULL, but if I remove the * for the outputs I can pick up the strings fine, is this a limitation?
>>>>>>> 
>>>>>>> 
>>>>>>>> On 12 Aug 2014, at 00:07, Steven Yi  wrote:
>>>>>>>> 
>>>>>>>> I think in this case, maybe Ed could try using * which is a var-arg of
>>>>>>>> any type.  So maybe try using "S*".  I see that * is in the list of
>>>>>>>> characters accepted for var-arg in-args. (It looks like I added that
>>>>>>>> for xout...) I seem to remember a long email to the dev list about
>>>>>>>> using ? for an optional arg of any type, * for var-arg of any type,
>>>>>>>> and . for a mandatory arg of any type. This would have been about a
>>>>>>>> year and a half ago, as I probably wrote about it while we were in the
>>>>>>>> thick of getting 6.0.0 out the door.
>>>>>>>> 
>>>>>>>> Ed, give that a go and see if that does the job. You could also check
>>>>>>>> in the init-function of your opcode the types at runtime to verify
>>>>>>>> that they are the kind you are expecting (k[], s, k[],s[], etc.).
>>>>>>>> 
>>>>>>>> Victor: regarding m, I think we should hold off at the moment.  We
>>>>>>>> really should get rid of the single-letter args that are representing
>>>>>>>> var-args and optional-args, and replace it with a more advanced arg
>>>>>>>> notation, such as:
>>>>>>>> 
>>>>>>>> "akk(43)i(0)k*"
>>>>>>>> 
>>>>>>>> or something like that, where ak would be mandatory, k(43) would be
>>>>>>>> optional with default value 43, and the last k* would mean var-arg of
>>>>>>>> k-type.  (That syntax looks horrible, so let's not use it, but it
>>>>>>>> illustrates the idea.)
>>>>>>>> 
>>>>>>>> Python has nice ways to define var-args and optional-args, i.e.:
>>>>>>>> 
>>>>>>>> def myFunc(var1,var2, var3 = 440, *args):
>>>>>>>> doSomething()
>>>>>>>> 
>>>>>>>> There's also some issues in dealing with the older notation, because
>>>>>>>> the internal system bubbled up to user-level through UDO args.  I did
>>>>>>>> have an idea that we could freeze the older syntax for instr and
>>>>>>>> opcode, but introduce new ones with Instr and Opcode (using
>>>>>>>> capitalized names).  That way, we could change the syntax of UDO's to
>>>>>>>> be something like:
>>>>>>>> 
>>>>>>>> Opcode MyOpcode (kvar, avar, Sval, asigs[], ksigs[])
>>>>>>>> kval = 5
>>>>>>>> return kval
>>>>>>>> end
>>>>>>>> 
>>>>>>>> where return would function similarly to xout.  Also, have named args
>>>>>>>> would allow easy interop with the type system. Sort of just
>>>>>>>> speculation though, maybe the syntax is a bit too different, I'm not
>>>>>>>> sure.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Mon, Aug 11, 2014 at 4:24 PM, Victor Lazzarini
>>>>>>>>  wrote:
>>>>>>>>> I think "m" is only matching scalars not arrays. Should it be changed?
>>>>>>>>> 
>>>>>>>>> Victor
>>>>>>>>> On 11 Aug 2014, at 21:08, Edward Costello wrote:
>>>>>>>>> 
>>>>>>>>>> I tried “Sk[]Sm” and that fails, the parser won’t parse the csd with any string array pairs after the first ones.
>>>>>>>>>> As a test I just put in scalar k rate variables after the first array string pair and it worked though, does anyone know where I am going wrong?
>>>>>>>>>> Ed
>>>>>>>>>> 
>>>>>>>>>> On 11 Aug 2014, at 19:39, Edward Costello  wrote:
>>>>>>>>>> 
>>>>>>>>>>> My original intypes entry was "Sk[]S”, should it just work if I change it to “m” ? I tried doing that and it’s complaining that it cannot find an opcode with matching argument types.
>>>>>>>>>>> 
>>>>>>>>>>> On 11 Aug 2014, at 13:06, Edward Costello  wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> Ok, thanks
>>>>>>>>>>>> Ed
>>>>>>>>>>>> 
>>>>>>>>>>>> On 11 Aug 2014, at 12:18, Victor Lazzarini  wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> You will need to use a generic “all inputs” code: m
>>>>>>>>>>>>> ========================
>>>>>>>>>>>>> Dr Victor Lazzarini
>>>>>>>>>>>>> Senior Lecturer
>>>>>>>>>>>>> NUI Maynooth, Ireland
>>>>>>>>>>>>> victor dot lazzarini at nuim dot ie
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On 11 Aug 2014, at 11:14, jpff@cs.bath.ac.uk wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> No such code exists
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Quoting Edward Costello :
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I am writing an opcode and I was just wondering what the magic
>>>>>>>>>>>>>>> letters are for intypes for an opcode that takes a string then a
>>>>>>>>>>>>>>> variable size of k-rate array and string pairs.
>>>>>>>>>>>>>>> For example: SFilename, karray1, Sdataset1, karray2, Sdataset2,
>>>>>>>>>>>>>>> karray3, Sdataset3,...
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>> Ed
>>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>> 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
>>>>>>>>>>> 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
>>>>>>>>> 
>>>>>>>>> Dr Victor Lazzarini
>>>>>>>>> Senior Lecturer
>>>>>>>>> Dept. of Music
>>>>>>>>> NUI Maynooth Ireland
>>>>>>>>> tel.: +353 1 708 3545
>>>>>>>>> Victor dot Lazzarini AT nuim dot ie
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>>>>> 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
>>>>> 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
>>> 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
> https://lists.sourceforge.net/lists/listinfo/csound-devel


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

If the license is LGPL, you just need to add the standard words at the top of the file. The manual page
is in xml like the others in the manual sources.
========================
Dr Victor Lazzarini
Senior Lecturer
NUI Maynooth, Ireland
victor dot lazzarini at nuim dot ie




On 14 Aug 2014, at 21:25, Edward Costello  wrote:

> Yeah sure, whats needed, a license on the sources and a manual page? 
> 
>> On 14 Aug 2014, at 22:11, Victor Lazzarini  wrote:
>> 
>> Can you contribute these to the Csound sources (+ manual)?
>> ========================
>> Dr Victor Lazzarini
>> Senior Lecturer
>> NUI Maynooth, Ireland
>> victor dot lazzarini at nuim dot ie
>> 
>> 
>> 
>> 
>> On 14 Aug 2014, at 20:57, Edward Costello  wrote:
>> 
>>> Yeah, the solution in this case is to use just a single MYFLT array for all arguments. In case anyone is interested I just wrote opcodes for reading and writing arrays to hdf5 files. This is handy as they can be read by matlab and a few other things like R and python. The read opcode can read multiple data sets from a single file at i-time, and the write opcode can write multiple datasets at a time to a single file at k-rate.
>>> 
>>> Ed
>>> 
>>> 
>>>> On 14 Aug 2014, at 21:15, Victor Lazzarini  wrote:
>>>> 
>>>> Interestingly, diskin has this for OENTRY 
>>>> 
>>>> { "diskin",S(DISKIN2),0, 5,    "mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm",
>>>> "Skooooooo”, ...
>>>> 
>>>> and
>>>> …
>>>> OPDS    h;
>>>> MYFLT   *aOut[DISKIN2_MAXCHN];
>>>> 
>>>> and
>>>> 
>>>> #define DISKIN2_MAXCHN  40   
>>>> 
>>>> ========================
>>>> Dr Victor Lazzarini
>>>> Senior Lecturer
>>>> NUI Maynooth, Ireland
>>>> victor dot lazzarini at nuim dot ie
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On 14 Aug 2014, at 19:57, Steven Yi  wrote:
>>>> 
>>>>> Hm, this could well be an issue with var-arg outputs and how to use it
>>>>> in your code.  Check subinstr.  The data struct for it is in
>>>>> H/insert.h (SUBINST).  It only has one MYFLT ar*[VARGMAX] for all
>>>>> parameters, input and output.  I haven't had a chance to look, but my
>>>>> guess is that the compiler lays out the out-args right after the
>>>>> in-args in this case.  If so, you should be able to use OUTOCOUNT to
>>>>> count how many output args were actually given, to index into where
>>>>> the in-args start.
>>>>> 
>>>>> This makes sense, as to Csound, when it goes to set arg pointers, it's
>>>>> just indexing into memory and using either the OENTRY's arg specifiers
>>>>> as a guide, or using what args were given.
>>>>> 
>>>>> On Thu, Aug 14, 2014 at 2:29 PM, Victor Lazzarini
>>>>>  wrote:
>>>>>> I think there might be a bug lurking in here. I built and ran your opcode with the following line
>>>>>> 
>>>>>> i1, i2 opcodetest "hello", "hi", “ho"
>>>>>> 
>>>>>> and this is what the debugger tells me:
>>>>>> 
>>>>>> Process 97844 stopped
>>>>>> * thread #1: tid = 0x9d9c55, 0x0000000106fe8f15 testop.dylib`opcode_init(csound=0x0000000101001200, self=0x000000010705edf0) + 101 at testop.cpp:19, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
>>>>>> frame #0: 0x0000000106fe8f15 testop.dylib`opcode_init(csound=0x0000000101001200, self=0x000000010705edf0) + 101 at testop.cpp:19
>>>>>> 16       for (size_t i = 0; i < inputArgumentCount; ++i) {
>>>>>> 17
>>>>>> 18           STRINGDAT *currentString = (STRINGDAT *) self->inputArgs[i];
>>>>>> -> 19           csound->Message(csound, "%s", currentString->data);
>>>>>> 20       }
>>>>>> 21
>>>>>> 22       return OK;
>>>>>> (lldb) print ((STRINGDAT *)self->outputArgs[2])->data
>>>>>> (char *) $6 = 0x0000000100d7d730 "hello"
>>>>>> (lldb) print ((STRINGDAT *)self->outputArgs[3])->data
>>>>>> (char *) $7 = 0x0000000100d7d840 "hi"
>>>>>> (lldb) print ((STRINGDAT *)self->outputArgs[4])->data
>>>>>> (char *) $8 = 0x0000000100d7d950 “ho"
>>>>>> 
>>>>>> 
>>>>>> see? all of the arguments have been passed in the outputArgs[] array. That does not seem right, it looks
>>>>>> like a bug to me (in Csound).
>>>>>> 
>>>>>> Regards
>>>>>> ========================
>>>>>> Dr Victor Lazzarini
>>>>>> Senior Lecturer
>>>>>> NUI Maynooth, Ireland
>>>>>> victor dot lazzarini at nuim dot ie
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 14 Aug 2014, at 18:33, Edward Costello  wrote:
>>>>>> 
>>>>>>> This is a skeleton of the code I’m using, running this gives a segmentation fault. Am I not constructing the opcode correctly?
>>>>>>> 
>>>>>>> #import 
>>>>>>> 
>>>>>>> typedef struct _opcode
>>>>>>> {
>>>>>>> OPDS h;
>>>>>>> 
>>>>>>> MYFLT *outputArgs[VARGMAX]; //arrays
>>>>>>> MYFLT *inputArgs[VARGMAX]; //strings
>>>>>>> 
>>>>>>> } opcode;
>>>>>>> 
>>>>>>> int opcode_init(CSOUND *csound, opcode *self)
>>>>>>> {
>>>>>>> size_t inputArgumentCount = self->INOCOUNT;
>>>>>>> 
>>>>>>> for (size_t i = 0; i < inputArgumentCount; ++i) {
>>>>>>> 
>>>>>>>    STRINGDAT *currentString = (STRINGDAT *) self->inputArgs[i];
>>>>>>>    csound->Message(csound, "%s", currentString->data);
>>>>>>> }
>>>>>>> 
>>>>>>> return OK;
>>>>>>> }
>>>>>>> 
>>>>>>> 
>>>>>>> static OENTRY localops[] = {
>>>>>>> 
>>>>>>> {
>>>>>>>    .opname = "opcodetest",
>>>>>>>    .dsblksiz = sizeof(opcode),
>>>>>>>    .thread = 1,
>>>>>>>    .outypes = "*",
>>>>>>>    .intypes = "*",
>>>>>>>    .iopadr = (SUBR)opcode_init,
>>>>>>>    .kopadr = NULL,
>>>>>>>    .aopadr = NULL
>>>>>>> }
>>>>>>> };
>>>>>>> 
>>>>>>> LINKAGE
>>>>>>> 
>>>>>>> 
>>>>>>>> On 14 Aug 2014, at 00:31, Edward Costello  wrote:
>>>>>>>> 
>>>>>>>> Thanks the * seems to work, although I think there might be something wrong. When I use * for inputs and outputs where the inputs are all strings and the outputs all arrays, I am not able to get a pointer to my strings, they come out NULL, but if I remove the * for the outputs I can pick up the strings fine, is this a limitation?
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On 12 Aug 2014, at 00:07, Steven Yi  wrote:
>>>>>>>>> 
>>>>>>>>> I think in this case, maybe Ed could try using * which is a var-arg of
>>>>>>>>> any type.  So maybe try using "S*".  I see that * is in the list of
>>>>>>>>> characters accepted for var-arg in-args. (It looks like I added that
>>>>>>>>> for xout...) I seem to remember a long email to the dev list about
>>>>>>>>> using ? for an optional arg of any type, * for var-arg of any type,
>>>>>>>>> and . for a mandatory arg of any type. This would have been about a
>>>>>>>>> year and a half ago, as I probably wrote about it while we were in the
>>>>>>>>> thick of getting 6.0.0 out the door.
>>>>>>>>> 
>>>>>>>>> Ed, give that a go and see if that does the job. You could also check
>>>>>>>>> in the init-function of your opcode the types at runtime to verify
>>>>>>>>> that they are the kind you are expecting (k[], s, k[],s[], etc.).
>>>>>>>>> 
>>>>>>>>> Victor: regarding m, I think we should hold off at the moment.  We
>>>>>>>>> really should get rid of the single-letter args that are representing
>>>>>>>>> var-args and optional-args, and replace it with a more advanced arg
>>>>>>>>> notation, such as:
>>>>>>>>> 
>>>>>>>>> "akk(43)i(0)k*"
>>>>>>>>> 
>>>>>>>>> or something like that, where ak would be mandatory, k(43) would be
>>>>>>>>> optional with default value 43, and the last k* would mean var-arg of
>>>>>>>>> k-type.  (That syntax looks horrible, so let's not use it, but it
>>>>>>>>> illustrates the idea.)
>>>>>>>>> 
>>>>>>>>> Python has nice ways to define var-args and optional-args, i.e.:
>>>>>>>>> 
>>>>>>>>> def myFunc(var1,var2, var3 = 440, *args):
>>>>>>>>> doSomething()
>>>>>>>>> 
>>>>>>>>> There's also some issues in dealing with the older notation, because
>>>>>>>>> the internal system bubbled up to user-level through UDO args.  I did
>>>>>>>>> have an idea that we could freeze the older syntax for instr and
>>>>>>>>> opcode, but introduce new ones with Instr and Opcode (using
>>>>>>>>> capitalized names).  That way, we could change the syntax of UDO's to
>>>>>>>>> be something like:
>>>>>>>>> 
>>>>>>>>> Opcode MyOpcode (kvar, avar, Sval, asigs[], ksigs[])
>>>>>>>>> kval = 5
>>>>>>>>> return kval
>>>>>>>>> end
>>>>>>>>> 
>>>>>>>>> where return would function similarly to xout.  Also, have named args
>>>>>>>>> would allow easy interop with the type system. Sort of just
>>>>>>>>> speculation though, maybe the syntax is a bit too different, I'm not
>>>>>>>>> sure.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Mon, Aug 11, 2014 at 4:24 PM, Victor Lazzarini
>>>>>>>>>  wrote:
>>>>>>>>>> I think "m" is only matching scalars not arrays. Should it be changed?
>>>>>>>>>> 
>>>>>>>>>> Victor
>>>>>>>>>> On 11 Aug 2014, at 21:08, Edward Costello wrote:
>>>>>>>>>> 
>>>>>>>>>>> I tried “Sk[]Sm” and that fails, the parser won’t parse the csd with any string array pairs after the first ones.
>>>>>>>>>>> As a test I just put in scalar k rate variables after the first array string pair and it worked though, does anyone know where I am going wrong?
>>>>>>>>>>> Ed
>>>>>>>>>>> 
>>>>>>>>>>> On 11 Aug 2014, at 19:39, Edward Costello  wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> My original intypes entry was "Sk[]S”, should it just work if I change it to “m” ? I tried doing that and it’s complaining that it cannot find an opcode with matching argument types.
>>>>>>>>>>>> 
>>>>>>>>>>>> On 11 Aug 2014, at 13:06, Edward Costello  wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> Ok, thanks
>>>>>>>>>>>>> Ed
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On 11 Aug 2014, at 12:18, Victor Lazzarini  wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> You will need to use a generic “all inputs” code: m
>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>> Dr Victor Lazzarini
>>>>>>>>>>>>>> Senior Lecturer
>>>>>>>>>>>>>> NUI Maynooth, Ireland
>>>>>>>>>>>>>> victor dot lazzarini at nuim dot ie
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On 11 Aug 2014, at 11:14, jpff@cs.bath.ac.uk wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> No such code exists
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Quoting Edward Costello :
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> I am writing an opcode and I was just wondering what the magic
>>>>>>>>>>>>>>>> letters are for intypes for an opcode that takes a string then a
>>>>>>>>>>>>>>>> variable size of k-rate array and string pairs.
>>>>>>>>>>>>>>>> For example: SFilename, karray1, Sdataset1, karray2, Sdataset2,
>>>>>>>>>>>>>>>> karray3, Sdataset3,...
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>> Ed
>>>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>> 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
>>>>>>>>>>>> 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
>>>>>>>>>> 
>>>>>>>>>> Dr Victor Lazzarini
>>>>>>>>>> Senior Lecturer
>>>>>>>>>> Dept. of Music
>>>>>>>>>> NUI Maynooth Ireland
>>>>>>>>>> tel.: +353 1 708 3545
>>>>>>>>>> Victor dot Lazzarini AT nuim dot ie
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>> _______________________________________________
>>>>>>>>>> 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
>>>>>>>> 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
>>>>>> 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
>>>> 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
>> 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