Following our conclusion that liblo seems to be overly heavy weight for OSC sending, I have
implemented an alternative version that uses UDP sockets directly. It is currently called
OSCsend2 and the interface is exactly the same to OSCsend. In our tests, it appears to
do the job, but have not tested it extensively.

It has been suggested to remove OSCsend and replace it with OSCsend2, so I would
like to check if OSCsend users could test OSCsend2 and let us know if there are differences
and whether it works OK for you. We would also then like to know whether having
OSCsend2 alongside OSCsend is your preference, or whether we should just replace it.

========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I would be happy to test the new OSCsend2. But is there a way to compile 
only this opcode from source, without doing the whole X-code build (I am 
on OSX)? E.g. with cc?
Best,
Andreas
> Following our conclusion that liblo seems to be overly heavy weight for OSC sending, I have
> implemented an alternative version that uses UDP sockets directly. It is currently called
> OSCsend2 and the interface is exactly the same to OSCsend. In our tests, it appears to
> do the job, but have not tested it extensively.
>
> It has been suggested to remove OSCsend and replace it with OSCsend2, so I would
> like to check if OSCsend users could test OSCsend2 and let us know if there are differences
> and whether it works OK for you. We would also then like to know whether having
> OSCsend2 alongside OSCsend is your preference, or whether we should just replace it.
>
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>          https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here


-- 
Andreas Bergsland

Associate professor - førsteamanuensis
Music Technology Programme - Musikkteknologiseksjonen
Department of Music - Institutt for musikk
Olavskvartalet
NTNU (Norwegian University of Science and Technology)
7491 Trondheim
NORWAY

Visiting address/besøksadresse: Fjordgt.1 (3.etg.)
e-mail: andreas.bergsland@ntnu.no
Web: http://folk.ntnu.no/andbe
Office phone: 7359 0096
Mobile:       4566 3316


Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I'll try it in a few moments. Are you going to replace OSClisten too? If
you do, please beware that right now receiving an array in Csound
expects the structure [dimensions(int); size(int); values(double)...]. I
had to bitshift and cast two ints as a double in order to make that work
from a third-party OSC library outside Csound. It didn't seem right and
I don't think it's possible in every programming language.

Cheers.


On 05/04/17 08:30, Victor Lazzarini wrote:
> Following our conclusion that liblo seems to be overly heavy weight for OSC sending, I have
> implemented an alternative version that uses UDP sockets directly. It is currently called
> OSCsend2 and the interface is exactly the same to OSCsend. In our tests, it appears to
> do the job, but have not tested it extensively.
>
> It has been suggested to remove OSCsend and replace it with OSCsend2, so I would
> like to check if OSCsend users could test OSCsend2 and let us know if there are differences
> and whether it works OK for you. We would also then like to know whether having
> OSCsend2 alongside OSCsend is your preference, or whether we should just replace it.
>
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952 
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I have implemented the array, audio and function table as per OSCsend/OSClisten. As far as I can see from the code, the blob is as you
describe, all data being sent in the native endianess (little endian for i386/x86_64). It could be that the OSC lib is expecting the data
in big-endian ints, 4 bytes at a time. As far as I understand, the OSC should not impose any particular interpretation to the blob,
but just take it as a string of bytes.

========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 5 Apr 2017, at 17:03, Guillermo Senna  wrote:
> 
> I'll try it in a few moments. Are you going to replace OSClisten too? If
> you do, please beware that right now receiving an array in Csound
> expects the structure [dimensions(int); size(int); values(double)...]. I
> had to bitshift and cast two ints as a double in order to make that work
> from a third-party OSC library outside Csound. It didn't seem right and
> I don't think it's possible in every programming language.
> 
> Cheers.
> 
> 
> On 05/04/17 08:30, Victor Lazzarini wrote:
>> Following our conclusion that liblo seems to be overly heavy weight for OSC sending, I have
>> implemented an alternative version that uses UDP sockets directly. It is currently called
>> OSCsend2 and the interface is exactly the same to OSCsend. In our tests, it appears to
>> do the job, but have not tested it extensively.
>> 
>> It has been suggested to remove OSCsend and replace it with OSCsend2, so I would
>> like to check if OSCsend users could test OSCsend2 and let us know if there are differences
>> and whether it works OK for you. We would also then like to know whether having
>> OSCsend2 alongside OSCsend is your preference, or whether we should just replace it.
>> 
>> ========================
>> Prof. Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy,
>> Maynooth University,
>> Maynooth, Co Kildare, Ireland
>> Tel: 00 353 7086936
>> Fax: 00 353 1 7086952 
>> 
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>        https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
> 
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Btw, there are no plans to replace OSClisten, as it works OK. OSC receiving (server) is considerably more
complicated than just sending the data. I think for that we shouldn’t reinvent the wheel.
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 5 Apr 2017, at 17:30, Victor Lazzarini  wrote:
> 
> I have implemented the array, audio and function table as per OSCsend/OSClisten. As far as I can see from the code, the blob is as you
> describe, all data being sent in the native endianess (little endian for i386/x86_64). It could be that the OSC lib is expecting the data
> in big-endian ints, 4 bytes at a time. As far as I understand, the OSC should not impose any particular interpretation to the blob,
> but just take it as a string of bytes.
> 
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952 
> 
>> On 5 Apr 2017, at 17:03, Guillermo Senna  wrote:
>> 
>> I'll try it in a few moments. Are you going to replace OSClisten too? If
>> you do, please beware that right now receiving an array in Csound
>> expects the structure [dimensions(int); size(int); values(double)...]. I
>> had to bitshift and cast two ints as a double in order to make that work
>> from a third-party OSC library outside Csound. It didn't seem right and
>> I don't think it's possible in every programming language.
>> 
>> Cheers.
>> 
>> 
>> On 05/04/17 08:30, Victor Lazzarini wrote:
>>> Following our conclusion that liblo seems to be overly heavy weight for OSC sending, I have
>>> implemented an alternative version that uses UDP sockets directly. It is currently called
>>> OSCsend2 and the interface is exactly the same to OSCsend. In our tests, it appears to
>>> do the job, but have not tested it extensively.
>>> 
>>> It has been suggested to remove OSCsend and replace it with OSCsend2, so I would
>>> like to check if OSCsend users could test OSCsend2 and let us know if there are differences
>>> and whether it works OK for you. We would also then like to know whether having
>>> OSCsend2 alongside OSCsend is your preference, or whether we should just replace it.
>>> 
>>> ========================
>>> Prof. Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy,
>>> Maynooth University,
>>> Maynooth, Co Kildare, Ireland
>>> Tel: 00 353 7086936
>>> Fax: 00 353 1 7086952 
>>> 
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>       https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>> 
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>       https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
> 
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here


Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Well I'm doing it in C++ with oscpack and for me it works. Now, I don't
know much about python for example, but if you are using a python module
for handling the OSC part of your program, is it possible to construct
the array to be sent as two ints and the rest as doubles?

I'm asking from complete ignorance, Victor. It just seemed odd to
(instead of passing my entire vector in C++) have to do something like this:

   unsigned long ui = qvlist.size();
    ui <<= 32; ui |= 1;
    vec.push_back (*(double*)&ui);


On 05/04/17 13:30, Victor Lazzarini wrote:
> I have implemented the array, audio and function table as per OSCsend/OSClisten. As far as I can see from the code, the blob is as you
> describe, all data being sent in the native endianess (little endian for i386/x86_64). It could be that the OSC lib is expecting the data
> in big-endian ints, 4 bytes at a time. As far as I understand, the OSC should not impose any particular interpretation to the blob,
> but just take it as a string of bytes.
>
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952 
>
>> On 5 Apr 2017, at 17:03, Guillermo Senna  wrote:
>>
>> I'll try it in a few moments. Are you going to replace OSClisten too? If
>> you do, please beware that right now receiving an array in Csound
>> expects the structure [dimensions(int); size(int); values(double)...]. I
>> had to bitshift and cast two ints as a double in order to make that work
>> from a third-party OSC library outside Csound. It didn't seem right and
>> I don't think it's possible in every programming language.
>>
>> Cheers.
>>
>>
>> On 05/04/17 08:30, Victor Lazzarini wrote:
>>> Following our conclusion that liblo seems to be overly heavy weight for OSC sending, I have
>>> implemented an alternative version that uses UDP sockets directly. It is currently called
>>> OSCsend2 and the interface is exactly the same to OSCsend. In our tests, it appears to
>>> do the job, but have not tested it extensively.
>>>
>>> It has been suggested to remove OSCsend and replace it with OSCsend2, so I would
>>> like to check if OSCsend users could test OSCsend2 and let us know if there are differences
>>> and whether it works OK for you. We would also then like to know whether having
>>> OSCsend2 alongside OSCsend is your preference, or whether we should just replace it.
>>>
>>> ========================
>>> Prof. Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy,
>>> Maynooth University,
>>> Maynooth, Co Kildare, Ireland
>>> Tel: 00 353 7086936
>>> Fax: 00 353 1 7086952 
>>>
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>        https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>        https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I would say keep the both for a while. Then, when most bugs are out, 
maybe replace OSCsend...

Richard


On 05/04/17 13:30, Victor Lazzarini wrote:
> Following our conclusion that liblo seems to be overly heavy weight for OSC sending, I have
> implemented an alternative version that uses UDP sockets directly. It is currently called
> OSCsend2 and the interface is exactly the same to OSCsend. In our tests, it appears to
> do the job, but have not tested it extensively.
>
> It has been suggested to remove OSCsend and replace it with OSCsend2, so I would
> like to check if OSCsend users could test OSCsend2 and let us know if there are differences
> and whether it works OK for you. We would also then like to know whether having
> OSCsend2 alongside OSCsend is your preference, or whether we should just replace it.
>
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>          https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Well, Csound reads two ints, as far as I can see. So I would expect that you can just send two
separate ints and Csound would understand it (first the dimension, then the size). This is
what OSCsend2 (& OSCsend) does. Not quite sure what might be going on at your end.
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 5 Apr 2017, at 17:44, Guillermo Senna  wrote:
> 
> Well I'm doing it in C++ with oscpack and for me it works. Now, I don't
> know much about python for example, but if you are using a python module
> for handling the OSC part of your program, is it possible to construct
> the array to be sent as two ints and the rest as doubles?
> 
> I'm asking from complete ignorance, Victor. It just seemed odd to
> (instead of passing my entire vector in C++) have to do something like this:
> 
>   unsigned long ui = qvlist.size();
>    ui <<= 32; ui |= 1;
>    vec.push_back (*(double*)&ui);
> 
> 
> On 05/04/17 13:30, Victor Lazzarini wrote:
>> I have implemented the array, audio and function table as per OSCsend/OSClisten. As far as I can see from the code, the blob is as you
>> describe, all data being sent in the native endianess (little endian for i386/x86_64). It could be that the OSC lib is expecting the data
>> in big-endian ints, 4 bytes at a time. As far as I understand, the OSC should not impose any particular interpretation to the blob,
>> but just take it as a string of bytes.
>> 
>> ========================
>> Prof. Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy,
>> Maynooth University,
>> Maynooth, Co Kildare, Ireland
>> Tel: 00 353 7086936
>> Fax: 00 353 1 7086952 
>> 
>>> On 5 Apr 2017, at 17:03, Guillermo Senna  wrote:
>>> 
>>> I'll try it in a few moments. Are you going to replace OSClisten too? If
>>> you do, please beware that right now receiving an array in Csound
>>> expects the structure [dimensions(int); size(int); values(double)...]. I
>>> had to bitshift and cast two ints as a double in order to make that work
>>> from a third-party OSC library outside Csound. It didn't seem right and
>>> I don't think it's possible in every programming language.
>>> 
>>> Cheers.
>>> 
>>> 
>>> On 05/04/17 08:30, Victor Lazzarini wrote:
>>>> Following our conclusion that liblo seems to be overly heavy weight for OSC sending, I have
>>>> implemented an alternative version that uses UDP sockets directly. It is currently called
>>>> OSCsend2 and the interface is exactly the same to OSCsend. In our tests, it appears to
>>>> do the job, but have not tested it extensively.
>>>> 
>>>> It has been suggested to remove OSCsend and replace it with OSCsend2, so I would
>>>> like to check if OSCsend users could test OSCsend2 and let us know if there are differences
>>>> and whether it works OK for you. We would also then like to know whether having
>>>> OSCsend2 alongside OSCsend is your preference, or whether we should just replace it.
>>>> 
>>>> ========================
>>>> Prof. Victor Lazzarini
>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>> Maynooth University,
>>>> Maynooth, Co Kildare, Ireland
>>>> Tel: 00 353 7086936
>>>> Fax: 00 353 1 7086952 
>>>> 
>>>> Csound mailing list
>>>> Csound@listserv.heanet.ie
>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>> Send bugs reports to
>>>>       https://github.com/csound/csound/issues
>>>> Discussions of bugs and features can be posted here
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>       https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>        https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
> 
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Sounds fine.

Hmm, in that case maybe it is better to replace OSCsend now, and keep the old one around as OSCsend_old for a while?

That way, we'll activate the use of the new one in all existing setups, and get to know about all things that go haywire. If no one complains after some months, we can delete OSsend_old.

2017-04-05 10:03 GMT-07:00 Richard <zappfinger@gmail.com>:

I would say keep the both for a while. Then, when most bugs are out, maybe replace OSCsend...

Richard


On 05/04/17 13:30, Victor Lazzarini wrote:

Following our conclusion that liblo seems to be overly heavy weight for OSC sending, I have
implemented an alternative version that uses UDP sockets directly. It is currently called
OSCsend2 and the interface is exactly the same to OSCsend. In our tests, it appears to
do the job, but have not tested it extensively.

It has been suggested to remove OSCsend and replace it with OSCsend2, so I would
like to check if OSCsend users could test OSCsend2 and let us know if there are differences
and whether it works OK for you. We would also then like to know whether having
OSCsend2 alongside OSCsend is your preference, or whether we should just replace it.

========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
         https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
       https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

--

Oeyvind Brandtsegg
Professor of Music Technology
NTNU
7491 Trondheim
Norway
Cell: +47 92 203 205

http://www.partikkelaudio.com/
http://crossadaptive.hf.ntnu.no
http://gdsp.hf.ntnu.no/
http://soundcloud.com/brandtsegg
http://flyndresang.no/
http://soundcloud.com/t-emp
 

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

My reasoning is that in the different programming languages you'd use a
library/module for handling the OSC part and that would in turn have
some abstraction for sending entire arrays as blobs. Now, Csound
requests for two 32-bit ints and then the rest 64-bits doubles. Is that
always possible to control in the higher-level languages?

Initially what I'd have thought is that I could build an array with all
doubles and Csound would internally truncate the first two values and
cast them into ints.

But if it's working for everyone right now nothing should be changed!


On 05/04/17 14:04, Victor Lazzarini wrote:
> Well, Csound reads two ints, as far as I can see. So I would expect that you can just send two
> separate ints and Csound would understand it (first the dimension, then the size). This is
> what OSCsend2 (& OSCsend) does. Not quite sure what might be going on at your end.
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952 
>
>> On 5 Apr 2017, at 17:44, Guillermo Senna  wrote:
>>
>> Well I'm doing it in C++ with oscpack and for me it works. Now, I don't
>> know much about python for example, but if you are using a python module
>> for handling the OSC part of your program, is it possible to construct
>> the array to be sent as two ints and the rest as doubles?
>>
>> I'm asking from complete ignorance, Victor. It just seemed odd to
>> (instead of passing my entire vector in C++) have to do something like this:
>>
>>   unsigned long ui = qvlist.size();
>>    ui <<= 32; ui |= 1;
>>    vec.push_back (*(double*)&ui);
>>
>>
>> On 05/04/17 13:30, Victor Lazzarini wrote:
>>> I have implemented the array, audio and function table as per OSCsend/OSClisten. As far as I can see from the code, the blob is as you
>>> describe, all data being sent in the native endianess (little endian for i386/x86_64). It could be that the OSC lib is expecting the data
>>> in big-endian ints, 4 bytes at a time. As far as I understand, the OSC should not impose any particular interpretation to the blob,
>>> but just take it as a string of bytes.
>>>
>>> ========================
>>> Prof. Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy,
>>> Maynooth University,
>>> Maynooth, Co Kildare, Ireland
>>> Tel: 00 353 7086936
>>> Fax: 00 353 1 7086952 
>>>
>>>> On 5 Apr 2017, at 17:03, Guillermo Senna  wrote:
>>>>
>>>> I'll try it in a few moments. Are you going to replace OSClisten too? If
>>>> you do, please beware that right now receiving an array in Csound
>>>> expects the structure [dimensions(int); size(int); values(double)...]. I
>>>> had to bitshift and cast two ints as a double in order to make that work
>>>> from a third-party OSC library outside Csound. It didn't seem right and
>>>> I don't think it's possible in every programming language.
>>>>
>>>> Cheers.
>>>>
>>>>
>>>> On 05/04/17 08:30, Victor Lazzarini wrote:
>>>>> Following our conclusion that liblo seems to be overly heavy weight for OSC sending, I have
>>>>> implemented an alternative version that uses UDP sockets directly. It is currently called
>>>>> OSCsend2 and the interface is exactly the same to OSCsend. In our tests, it appears to
>>>>> do the job, but have not tested it extensively.
>>>>>
>>>>> It has been suggested to remove OSCsend and replace it with OSCsend2, so I would
>>>>> like to check if OSCsend users could test OSCsend2 and let us know if there are differences
>>>>> and whether it works OK for you. We would also then like to know whether having
>>>>> OSCsend2 alongside OSCsend is your preference, or whether we should just replace it.
>>>>>
>>>>> ========================
>>>>> Prof. Victor Lazzarini
>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>> Maynooth University,
>>>>> Maynooth, Co Kildare, Ireland
>>>>> Tel: 00 353 7086936
>>>>> Fax: 00 353 1 7086952 
>>>>>
>>>>> Csound mailing list
>>>>> Csound@listserv.heanet.ie
>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>> Send bugs reports to
>>>>>       https://github.com/csound/csound/issues
>>>>> Discussions of bugs and features can be posted here
>>>> Csound mailing list
>>>> Csound@listserv.heanet.ie
>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>> Send bugs reports to
>>>>       https://github.com/csound/csound/issues
>>>> Discussions of bugs and features can be posted here
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>        https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>        https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I see what you mean. It’s possible to change it, there are two options:

1) encode everything with doubles
2) leave dim and size. The size of the blob is always there before the
data, so we can just use that. It will be then up to the user to interpret
the data as a 1,2,3 ,… dimensional array. The data is always stored
as a flat vector (e.g. row-column for 2-d).

if people want it changed, I can do it.
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 5 Apr 2017, at 18:24, Guillermo Senna  wrote:
> 
> My reasoning is that in the different programming languages you'd use a
> library/module for handling the OSC part and that would in turn have
> some abstraction for sending entire arrays as blobs. Now, Csound
> requests for two 32-bit ints and then the rest 64-bits doubles. Is that
> always possible to control in the higher-level languages?
> 
> Initially what I'd have thought is that I could build an array with all
> doubles and Csound would internally truncate the first two values and
> cast them into ints.
> 
> But if it's working for everyone right now nothing should be changed!
> 
> 
> On 05/04/17 14:04, Victor Lazzarini wrote:
>> Well, Csound reads two ints, as far as I can see. So I would expect that you can just send two
>> separate ints and Csound would understand it (first the dimension, then the size). This is
>> what OSCsend2 (& OSCsend) does. Not quite sure what might be going on at your end.
>> ========================
>> Prof. Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy,
>> Maynooth University,
>> Maynooth, Co Kildare, Ireland
>> Tel: 00 353 7086936
>> Fax: 00 353 1 7086952 
>> 
>>> On 5 Apr 2017, at 17:44, Guillermo Senna  wrote:
>>> 
>>> Well I'm doing it in C++ with oscpack and for me it works. Now, I don't
>>> know much about python for example, but if you are using a python module
>>> for handling the OSC part of your program, is it possible to construct
>>> the array to be sent as two ints and the rest as doubles?
>>> 
>>> I'm asking from complete ignorance, Victor. It just seemed odd to
>>> (instead of passing my entire vector in C++) have to do something like this:
>>> 
>>>  unsigned long ui = qvlist.size();
>>>   ui <<= 32; ui |= 1;
>>>   vec.push_back (*(double*)&ui);
>>> 
>>> 
>>> On 05/04/17 13:30, Victor Lazzarini wrote:
>>>> I have implemented the array, audio and function table as per OSCsend/OSClisten. As far as I can see from the code, the blob is as you
>>>> describe, all data being sent in the native endianess (little endian for i386/x86_64). It could be that the OSC lib is expecting the data
>>>> in big-endian ints, 4 bytes at a time. As far as I understand, the OSC should not impose any particular interpretation to the blob,
>>>> but just take it as a string of bytes.
>>>> 
>>>> ========================
>>>> Prof. Victor Lazzarini
>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>> Maynooth University,
>>>> Maynooth, Co Kildare, Ireland
>>>> Tel: 00 353 7086936
>>>> Fax: 00 353 1 7086952 
>>>> 
>>>>> On 5 Apr 2017, at 17:03, Guillermo Senna  wrote:
>>>>> 
>>>>> I'll try it in a few moments. Are you going to replace OSClisten too? If
>>>>> you do, please beware that right now receiving an array in Csound
>>>>> expects the structure [dimensions(int); size(int); values(double)...]. I
>>>>> had to bitshift and cast two ints as a double in order to make that work
>>>>> from a third-party OSC library outside Csound. It didn't seem right and
>>>>> I don't think it's possible in every programming language.
>>>>> 
>>>>> Cheers.
>>>>> 
>>>>> 
>>>>> On 05/04/17 08:30, Victor Lazzarini wrote:
>>>>>> Following our conclusion that liblo seems to be overly heavy weight for OSC sending, I have
>>>>>> implemented an alternative version that uses UDP sockets directly. It is currently called
>>>>>> OSCsend2 and the interface is exactly the same to OSCsend. In our tests, it appears to
>>>>>> do the job, but have not tested it extensively.
>>>>>> 
>>>>>> It has been suggested to remove OSCsend and replace it with OSCsend2, so I would
>>>>>> like to check if OSCsend users could test OSCsend2 and let us know if there are differences
>>>>>> and whether it works OK for you. We would also then like to know whether having
>>>>>> OSCsend2 alongside OSCsend is your preference, or whether we should just replace it.
>>>>>> 
>>>>>> ========================
>>>>>> Prof. Victor Lazzarini
>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>> Maynooth University,
>>>>>> Maynooth, Co Kildare, Ireland
>>>>>> Tel: 00 353 7086936
>>>>>> Fax: 00 353 1 7086952 
>>>>>> 
>>>>>> Csound mailing list
>>>>>> Csound@listserv.heanet.ie
>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>> Send bugs reports to
>>>>>>      https://github.com/csound/csound/issues
>>>>>> Discussions of bugs and features can be posted here
>>>>> Csound mailing list
>>>>> Csound@listserv.heanet.ie
>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>> Send bugs reports to
>>>>>      https://github.com/csound/csound/issues
>>>>> Discussions of bugs and features can be posted here
>>>> Csound mailing list
>>>> Csound@listserv.heanet.ie
>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>> Send bugs reports to
>>>>       https://github.com/csound/csound/issues
>>>> Discussions of bugs and features can be posted here
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>       https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>        https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
> 
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here


Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Unfortunately it’s not a plugin, so Csound needs to be re-built with it.
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 5 Apr 2017, at 13:26, Andreas Bergsland  wrote:
> 
> I would be happy to test the new OSCsend2. But is there a way to compile only this opcode from source, without doing the whole X-code build (I am on OSX)? E.g. with cc?
> Best,
> Andreas
>> Following our conclusion that liblo seems to be overly heavy weight for OSC sending, I have
>> implemented an alternative version that uses UDP sockets directly. It is currently called
>> OSCsend2 and the interface is exactly the same to OSCsend. In our tests, it appears to
>> do the job, but have not tested it extensively.
>> 
>> It has been suggested to remove OSCsend and replace it with OSCsend2, so I would
>> like to check if OSCsend users could test OSCsend2 and let us know if there are differences
>> and whether it works OK for you. We would also then like to know whether having
>> OSCsend2 alongside OSCsend is your preference, or whether we should just replace it.
>> 
>> ========================
>> Prof. Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy,
>> Maynooth University,
>> Maynooth, Co Kildare, Ireland
>> Tel: 00 353 7086936
>> Fax: 00 353 1 7086952
>> 
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>         https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
> 
> 
> -- 
> Andreas Bergsland
> 
> Associate professor - førsteamanuensis
> Music Technology Programme - Musikkteknologiseksjonen
> Department of Music - Institutt for musikk
> Olavskvartalet
> NTNU (Norwegian University of Science and Technology)
> 7491 Trondheim
> NORWAY
> 
> Visiting address/besøksadresse: Fjordgt.1 (3.etg.)
> e-mail: andreas.bergsland@ntnu.no
> Web: http://folk.ntnu.no/andbe
> Office phone: 7359 0096
> Mobile:       4566 3316
> 
> 
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>       https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
> 


Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I've not considered number 2 before. How about adding an opcode later
for joining 2d arrays into a single multidimensional? Would it be to
difficult/inefficient to do that considering that in the end it's all
about pointers?

I don't want to change and break it for others already using the current
structure.


On 05/04/17 18:12, Victor Lazzarini wrote:
> I see what you mean. It’s possible to change it, there are two options:
>
> 1) encode everything with doubles
> 2) leave dim and size. The size of the blob is always there before the
> data, so we can just use that. It will be then up to the user to interpret
> the data as a 1,2,3 ,… dimensional array. The data is always stored
> as a flat vector (e.g. row-column for 2-d).
>
> if people want it changed, I can do it.
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952 
>
>> On 5 Apr 2017, at 18:24, Guillermo Senna  wrote:
>>
>> My reasoning is that in the different programming languages you'd use a
>> library/module for handling the OSC part and that would in turn have
>> some abstraction for sending entire arrays as blobs. Now, Csound
>> requests for two 32-bit ints and then the rest 64-bits doubles. Is that
>> always possible to control in the higher-level languages?
>>
>> Initially what I'd have thought is that I could build an array with all
>> doubles and Csound would internally truncate the first two values and
>> cast them into ints.
>>
>> But if it's working for everyone right now nothing should be changed!
>>
>>
>> On 05/04/17 14:04, Victor Lazzarini wrote:
>>> Well, Csound reads two ints, as far as I can see. So I would expect that you can just send two
>>> separate ints and Csound would understand it (first the dimension, then the size). This is
>>> what OSCsend2 (& OSCsend) does. Not quite sure what might be going on at your end.
>>> ========================
>>> Prof. Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy,
>>> Maynooth University,
>>> Maynooth, Co Kildare, Ireland
>>> Tel: 00 353 7086936
>>> Fax: 00 353 1 7086952 
>>>
>>>> On 5 Apr 2017, at 17:44, Guillermo Senna  wrote:
>>>>
>>>> Well I'm doing it in C++ with oscpack and for me it works. Now, I don't
>>>> know much about python for example, but if you are using a python module
>>>> for handling the OSC part of your program, is it possible to construct
>>>> the array to be sent as two ints and the rest as doubles?
>>>>
>>>> I'm asking from complete ignorance, Victor. It just seemed odd to
>>>> (instead of passing my entire vector in C++) have to do something like this:
>>>>
>>>>  unsigned long ui = qvlist.size();
>>>>   ui <<= 32; ui |= 1;
>>>>   vec.push_back (*(double*)&ui);
>>>>
>>>>
>>>> On 05/04/17 13:30, Victor Lazzarini wrote:
>>>>> I have implemented the array, audio and function table as per OSCsend/OSClisten. As far as I can see from the code, the blob is as you
>>>>> describe, all data being sent in the native endianess (little endian for i386/x86_64). It could be that the OSC lib is expecting the data
>>>>> in big-endian ints, 4 bytes at a time. As far as I understand, the OSC should not impose any particular interpretation to the blob,
>>>>> but just take it as a string of bytes.
>>>>>
>>>>> ========================
>>>>> Prof. Victor Lazzarini
>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>> Maynooth University,
>>>>> Maynooth, Co Kildare, Ireland
>>>>> Tel: 00 353 7086936
>>>>> Fax: 00 353 1 7086952 
>>>>>
>>>>>> On 5 Apr 2017, at 17:03, Guillermo Senna  wrote:
>>>>>>
>>>>>> I'll try it in a few moments. Are you going to replace OSClisten too? If
>>>>>> you do, please beware that right now receiving an array in Csound
>>>>>> expects the structure [dimensions(int); size(int); values(double)...]. I
>>>>>> had to bitshift and cast two ints as a double in order to make that work
>>>>>> from a third-party OSC library outside Csound. It didn't seem right and
>>>>>> I don't think it's possible in every programming language.
>>>>>>
>>>>>> Cheers.
>>>>>>
>>>>>>
>>>>>> On 05/04/17 08:30, Victor Lazzarini wrote:
>>>>>>> Following our conclusion that liblo seems to be overly heavy weight for OSC sending, I have
>>>>>>> implemented an alternative version that uses UDP sockets directly. It is currently called
>>>>>>> OSCsend2 and the interface is exactly the same to OSCsend. In our tests, it appears to
>>>>>>> do the job, but have not tested it extensively.
>>>>>>>
>>>>>>> It has been suggested to remove OSCsend and replace it with OSCsend2, so I would
>>>>>>> like to check if OSCsend users could test OSCsend2 and let us know if there are differences
>>>>>>> and whether it works OK for you. We would also then like to know whether having
>>>>>>> OSCsend2 alongside OSCsend is your preference, or whether we should just replace it.
>>>>>>>
>>>>>>> ========================
>>>>>>> Prof. Victor Lazzarini
>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>> Maynooth University,
>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>> Tel: 00 353 7086936
>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>
>>>>>>> Csound mailing list
>>>>>>> Csound@listserv.heanet.ie
>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>> Send bugs reports to
>>>>>>>      https://github.com/csound/csound/issues
>>>>>>> Discussions of bugs and features can be posted here
>>>>>> Csound mailing list
>>>>>> Csound@listserv.heanet.ie
>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>> Send bugs reports to
>>>>>>      https://github.com/csound/csound/issues
>>>>>> Discussions of bugs and features can be posted here
>>>>> Csound mailing list
>>>>> Csound@listserv.heanet.ie
>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>> Send bugs reports to
>>>>>       https://github.com/csound/csound/issues
>>>>> Discussions of bugs and features can be posted here
>>>> Csound mailing list
>>>> Csound@listserv.heanet.ie
>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>> Send bugs reports to
>>>>       https://github.com/csound/csound/issues
>>>> Discussions of bugs and features can be posted here
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>        https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>        https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

With number 2, you could pass any array of any number of dimensions. It would be up
to you to decide how to package the data.

========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 6 Apr 2017, at 21:04, Guillermo Senna  wrote:
> 
> I've not considered number 2 before. How about adding an opcode later
> for joining 2d arrays into a single multidimensional? Would it be to
> difficult/inefficient to do that considering that in the end it's all
> about pointers?
> 
> I don't want to change and break it for others already using the current
> structure.
> 
> 
> On 05/04/17 18:12, Victor Lazzarini wrote:
>> I see what you mean. It’s possible to change it, there are two options:
>> 
>> 1) encode everything with doubles
>> 2) leave dim and size. The size of the blob is always there before the
>> data, so we can just use that. It will be then up to the user to interpret
>> the data as a 1,2,3 ,… dimensional array. The data is always stored
>> as a flat vector (e.g. row-column for 2-d).
>> 
>> if people want it changed, I can do it.
>> ========================
>> Prof. Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy,
>> Maynooth University,
>> Maynooth, Co Kildare, Ireland
>> Tel: 00 353 7086936
>> Fax: 00 353 1 7086952 
>> 
>>> On 5 Apr 2017, at 18:24, Guillermo Senna  wrote:
>>> 
>>> My reasoning is that in the different programming languages you'd use a
>>> library/module for handling the OSC part and that would in turn have
>>> some abstraction for sending entire arrays as blobs. Now, Csound
>>> requests for two 32-bit ints and then the rest 64-bits doubles. Is that
>>> always possible to control in the higher-level languages?
>>> 
>>> Initially what I'd have thought is that I could build an array with all
>>> doubles and Csound would internally truncate the first two values and
>>> cast them into ints.
>>> 
>>> But if it's working for everyone right now nothing should be changed!
>>> 
>>> 
>>> On 05/04/17 14:04, Victor Lazzarini wrote:
>>>> Well, Csound reads two ints, as far as I can see. So I would expect that you can just send two
>>>> separate ints and Csound would understand it (first the dimension, then the size). This is
>>>> what OSCsend2 (& OSCsend) does. Not quite sure what might be going on at your end.
>>>> ========================
>>>> Prof. Victor Lazzarini
>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>> Maynooth University,
>>>> Maynooth, Co Kildare, Ireland
>>>> Tel: 00 353 7086936
>>>> Fax: 00 353 1 7086952 
>>>> 
>>>>> On 5 Apr 2017, at 17:44, Guillermo Senna  wrote:
>>>>> 
>>>>> Well I'm doing it in C++ with oscpack and for me it works. Now, I don't
>>>>> know much about python for example, but if you are using a python module
>>>>> for handling the OSC part of your program, is it possible to construct
>>>>> the array to be sent as two ints and the rest as doubles?
>>>>> 
>>>>> I'm asking from complete ignorance, Victor. It just seemed odd to
>>>>> (instead of passing my entire vector in C++) have to do something like this:
>>>>> 
>>>>> unsigned long ui = qvlist.size();
>>>>>  ui <<= 32; ui |= 1;
>>>>>  vec.push_back (*(double*)&ui);
>>>>> 
>>>>> 
>>>>> On 05/04/17 13:30, Victor Lazzarini wrote:
>>>>>> I have implemented the array, audio and function table as per OSCsend/OSClisten. As far as I can see from the code, the blob is as you
>>>>>> describe, all data being sent in the native endianess (little endian for i386/x86_64). It could be that the OSC lib is expecting the data
>>>>>> in big-endian ints, 4 bytes at a time. As far as I understand, the OSC should not impose any particular interpretation to the blob,
>>>>>> but just take it as a string of bytes.
>>>>>> 
>>>>>> ========================
>>>>>> Prof. Victor Lazzarini
>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>> Maynooth University,
>>>>>> Maynooth, Co Kildare, Ireland
>>>>>> Tel: 00 353 7086936
>>>>>> Fax: 00 353 1 7086952 
>>>>>> 
>>>>>>> On 5 Apr 2017, at 17:03, Guillermo Senna  wrote:
>>>>>>> 
>>>>>>> I'll try it in a few moments. Are you going to replace OSClisten too? If
>>>>>>> you do, please beware that right now receiving an array in Csound
>>>>>>> expects the structure [dimensions(int); size(int); values(double)...]. I
>>>>>>> had to bitshift and cast two ints as a double in order to make that work
>>>>>>> from a third-party OSC library outside Csound. It didn't seem right and
>>>>>>> I don't think it's possible in every programming language.
>>>>>>> 
>>>>>>> Cheers.
>>>>>>> 
>>>>>>> 
>>>>>>> On 05/04/17 08:30, Victor Lazzarini wrote:
>>>>>>>> Following our conclusion that liblo seems to be overly heavy weight for OSC sending, I have
>>>>>>>> implemented an alternative version that uses UDP sockets directly. It is currently called
>>>>>>>> OSCsend2 and the interface is exactly the same to OSCsend. In our tests, it appears to
>>>>>>>> do the job, but have not tested it extensively.
>>>>>>>> 
>>>>>>>> It has been suggested to remove OSCsend and replace it with OSCsend2, so I would
>>>>>>>> like to check if OSCsend users could test OSCsend2 and let us know if there are differences
>>>>>>>> and whether it works OK for you. We would also then like to know whether having
>>>>>>>> OSCsend2 alongside OSCsend is your preference, or whether we should just replace it.
>>>>>>>> 
>>>>>>>> ========================
>>>>>>>> Prof. Victor Lazzarini
>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>> Maynooth University,
>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>> Tel: 00 353 7086936
>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>> 
>>>>>>>> Csound mailing list
>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>> Send bugs reports to
>>>>>>>>     https://github.com/csound/csound/issues
>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>> Csound mailing list
>>>>>>> Csound@listserv.heanet.ie
>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>> Send bugs reports to
>>>>>>>     https://github.com/csound/csound/issues
>>>>>>> Discussions of bugs and features can be posted here
>>>>>> Csound mailing list
>>>>>> Csound@listserv.heanet.ie
>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>> Send bugs reports to
>>>>>>      https://github.com/csound/csound/issues
>>>>>> Discussions of bugs and features can be posted here
>>>>> Csound mailing list
>>>>> Csound@listserv.heanet.ie
>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>> Send bugs reports to
>>>>>      https://github.com/csound/csound/issues
>>>>> Discussions of bugs and features can be posted here
>>>> Csound mailing list
>>>> Csound@listserv.heanet.ie
>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>> Send bugs reports to
>>>>       https://github.com/csound/csound/issues
>>>> Discussions of bugs and features can be posted here
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>       https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>> 
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>        https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
> 
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here


Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

We could put in a different type name for non-descript double-format data sequence (e.g. 2), for instance
call it “D”.
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 6 Apr 2017, at 21:04, Guillermo Senna  wrote:
> 
> I've not considered number 2 before. How about adding an opcode later
> for joining 2d arrays into a single multidimensional? Would it be to
> difficult/inefficient to do that considering that in the end it's all
> about pointers?
> 
> I don't want to change and break it for others already using the current
> structure.
> 
> 
> On 05/04/17 18:12, Victor Lazzarini wrote:
>> I see what you mean. It’s possible to change it, there are two options:
>> 
>> 1) encode everything with doubles
>> 2) leave dim and size. The size of the blob is always there before the
>> data, so we can just use that. It will be then up to the user to interpret
>> the data as a 1,2,3 ,… dimensional array. The data is always stored
>> as a flat vector (e.g. row-column for 2-d).
>> 
>> if people want it changed, I can do it.
>> ========================
>> Prof. Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy,
>> Maynooth University,
>> Maynooth, Co Kildare, Ireland
>> Tel: 00 353 7086936
>> Fax: 00 353 1 7086952 
>> 
>>> On 5 Apr 2017, at 18:24, Guillermo Senna  wrote:
>>> 
>>> My reasoning is that in the different programming languages you'd use a
>>> library/module for handling the OSC part and that would in turn have
>>> some abstraction for sending entire arrays as blobs. Now, Csound
>>> requests for two 32-bit ints and then the rest 64-bits doubles. Is that
>>> always possible to control in the higher-level languages?
>>> 
>>> Initially what I'd have thought is that I could build an array with all
>>> doubles and Csound would internally truncate the first two values and
>>> cast them into ints.
>>> 
>>> But if it's working for everyone right now nothing should be changed!
>>> 
>>> 
>>> On 05/04/17 14:04, Victor Lazzarini wrote:
>>>> Well, Csound reads two ints, as far as I can see. So I would expect that you can just send two
>>>> separate ints and Csound would understand it (first the dimension, then the size). This is
>>>> what OSCsend2 (& OSCsend) does. Not quite sure what might be going on at your end.
>>>> ========================
>>>> Prof. Victor Lazzarini
>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>> Maynooth University,
>>>> Maynooth, Co Kildare, Ireland
>>>> Tel: 00 353 7086936
>>>> Fax: 00 353 1 7086952 
>>>> 
>>>>> On 5 Apr 2017, at 17:44, Guillermo Senna  wrote:
>>>>> 
>>>>> Well I'm doing it in C++ with oscpack and for me it works. Now, I don't
>>>>> know much about python for example, but if you are using a python module
>>>>> for handling the OSC part of your program, is it possible to construct
>>>>> the array to be sent as two ints and the rest as doubles?
>>>>> 
>>>>> I'm asking from complete ignorance, Victor. It just seemed odd to
>>>>> (instead of passing my entire vector in C++) have to do something like this:
>>>>> 
>>>>> unsigned long ui = qvlist.size();
>>>>>  ui <<= 32; ui |= 1;
>>>>>  vec.push_back (*(double*)&ui);
>>>>> 
>>>>> 
>>>>> On 05/04/17 13:30, Victor Lazzarini wrote:
>>>>>> I have implemented the array, audio and function table as per OSCsend/OSClisten. As far as I can see from the code, the blob is as you
>>>>>> describe, all data being sent in the native endianess (little endian for i386/x86_64). It could be that the OSC lib is expecting the data
>>>>>> in big-endian ints, 4 bytes at a time. As far as I understand, the OSC should not impose any particular interpretation to the blob,
>>>>>> but just take it as a string of bytes.
>>>>>> 
>>>>>> ========================
>>>>>> Prof. Victor Lazzarini
>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>> Maynooth University,
>>>>>> Maynooth, Co Kildare, Ireland
>>>>>> Tel: 00 353 7086936
>>>>>> Fax: 00 353 1 7086952 
>>>>>> 
>>>>>>> On 5 Apr 2017, at 17:03, Guillermo Senna  wrote:
>>>>>>> 
>>>>>>> I'll try it in a few moments. Are you going to replace OSClisten too? If
>>>>>>> you do, please beware that right now receiving an array in Csound
>>>>>>> expects the structure [dimensions(int); size(int); values(double)...]. I
>>>>>>> had to bitshift and cast two ints as a double in order to make that work
>>>>>>> from a third-party OSC library outside Csound. It didn't seem right and
>>>>>>> I don't think it's possible in every programming language.
>>>>>>> 
>>>>>>> Cheers.
>>>>>>> 
>>>>>>> 
>>>>>>> On 05/04/17 08:30, Victor Lazzarini wrote:
>>>>>>>> Following our conclusion that liblo seems to be overly heavy weight for OSC sending, I have
>>>>>>>> implemented an alternative version that uses UDP sockets directly. It is currently called
>>>>>>>> OSCsend2 and the interface is exactly the same to OSCsend. In our tests, it appears to
>>>>>>>> do the job, but have not tested it extensively.
>>>>>>>> 
>>>>>>>> It has been suggested to remove OSCsend and replace it with OSCsend2, so I would
>>>>>>>> like to check if OSCsend users could test OSCsend2 and let us know if there are differences
>>>>>>>> and whether it works OK for you. We would also then like to know whether having
>>>>>>>> OSCsend2 alongside OSCsend is your preference, or whether we should just replace it.
>>>>>>>> 
>>>>>>>> ========================
>>>>>>>> Prof. Victor Lazzarini
>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>> Maynooth University,
>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>> Tel: 00 353 7086936
>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>> 
>>>>>>>> Csound mailing list
>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>> Send bugs reports to
>>>>>>>>     https://github.com/csound/csound/issues
>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>> Csound mailing list
>>>>>>> Csound@listserv.heanet.ie
>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>> Send bugs reports to
>>>>>>>     https://github.com/csound/csound/issues
>>>>>>> Discussions of bugs and features can be posted here
>>>>>> Csound mailing list
>>>>>> Csound@listserv.heanet.ie
>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>> Send bugs reports to
>>>>>>      https://github.com/csound/csound/issues
>>>>>> Discussions of bugs and features can be posted here
>>>>> Csound mailing list
>>>>> Csound@listserv.heanet.ie
>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>> Send bugs reports to
>>>>>      https://github.com/csound/csound/issues
>>>>> Discussions of bugs and features can be posted here
>>>> Csound mailing list
>>>> Csound@listserv.heanet.ie
>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>> Send bugs reports to
>>>>       https://github.com/csound/csound/issues
>>>> Discussions of bugs and features can be posted here
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>       https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>> 
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>        https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
> 
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here


Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I like that. Non of those characters are really part of the OSC
specification, so why not?

But with this approach you would still use a Csound array as xdata1 in
OSClisten, right?

On 06/04/17 17:16, Victor Lazzarini wrote:
> We could put in a different type name for non-descript double-format data sequence (e.g. 2), for instance
> call it “D”.
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952 
>
>> On 6 Apr 2017, at 21:04, Guillermo Senna  wrote:
>>
>> I've not considered number 2 before. How about adding an opcode later
>> for joining 2d arrays into a single multidimensional? Would it be to
>> difficult/inefficient to do that considering that in the end it's all
>> about pointers?
>>
>> I don't want to change and break it for others already using the current
>> structure.
>>
>>
>> On 05/04/17 18:12, Victor Lazzarini wrote:
>>> I see what you mean. It’s possible to change it, there are two options:
>>>
>>> 1) encode everything with doubles
>>> 2) leave dim and size. The size of the blob is always there before the
>>> data, so we can just use that. It will be then up to the user to interpret
>>> the data as a 1,2,3 ,… dimensional array. The data is always stored
>>> as a flat vector (e.g. row-column for 2-d).
>>>
>>> if people want it changed, I can do it.
>>> ========================
>>> Prof. Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy,
>>> Maynooth University,
>>> Maynooth, Co Kildare, Ireland
>>> Tel: 00 353 7086936
>>> Fax: 00 353 1 7086952 
>>>
>>>> On 5 Apr 2017, at 18:24, Guillermo Senna  wrote:
>>>>
>>>> My reasoning is that in the different programming languages you'd use a
>>>> library/module for handling the OSC part and that would in turn have
>>>> some abstraction for sending entire arrays as blobs. Now, Csound
>>>> requests for two 32-bit ints and then the rest 64-bits doubles. Is that
>>>> always possible to control in the higher-level languages?
>>>>
>>>> Initially what I'd have thought is that I could build an array with all
>>>> doubles and Csound would internally truncate the first two values and
>>>> cast them into ints.
>>>>
>>>> But if it's working for everyone right now nothing should be changed!
>>>>
>>>>
>>>> On 05/04/17 14:04, Victor Lazzarini wrote:
>>>>> Well, Csound reads two ints, as far as I can see. So I would expect that you can just send two
>>>>> separate ints and Csound would understand it (first the dimension, then the size). This is
>>>>> what OSCsend2 (& OSCsend) does. Not quite sure what might be going on at your end.
>>>>> ========================
>>>>> Prof. Victor Lazzarini
>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>> Maynooth University,
>>>>> Maynooth, Co Kildare, Ireland
>>>>> Tel: 00 353 7086936
>>>>> Fax: 00 353 1 7086952 
>>>>>
>>>>>> On 5 Apr 2017, at 17:44, Guillermo Senna  wrote:
>>>>>>
>>>>>> Well I'm doing it in C++ with oscpack and for me it works. Now, I don't
>>>>>> know much about python for example, but if you are using a python module
>>>>>> for handling the OSC part of your program, is it possible to construct
>>>>>> the array to be sent as two ints and the rest as doubles?
>>>>>>
>>>>>> I'm asking from complete ignorance, Victor. It just seemed odd to
>>>>>> (instead of passing my entire vector in C++) have to do something like this:
>>>>>>
>>>>>> unsigned long ui = qvlist.size();
>>>>>>  ui <<= 32; ui |= 1;
>>>>>>  vec.push_back (*(double*)&ui);
>>>>>>
>>>>>>
>>>>>> On 05/04/17 13:30, Victor Lazzarini wrote:
>>>>>>> I have implemented the array, audio and function table as per OSCsend/OSClisten. As far as I can see from the code, the blob is as you
>>>>>>> describe, all data being sent in the native endianess (little endian for i386/x86_64). It could be that the OSC lib is expecting the data
>>>>>>> in big-endian ints, 4 bytes at a time. As far as I understand, the OSC should not impose any particular interpretation to the blob,
>>>>>>> but just take it as a string of bytes.
>>>>>>>
>>>>>>> ========================
>>>>>>> Prof. Victor Lazzarini
>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>> Maynooth University,
>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>> Tel: 00 353 7086936
>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>
>>>>>>>> On 5 Apr 2017, at 17:03, Guillermo Senna  wrote:
>>>>>>>>
>>>>>>>> I'll try it in a few moments. Are you going to replace OSClisten too? If
>>>>>>>> you do, please beware that right now receiving an array in Csound
>>>>>>>> expects the structure [dimensions(int); size(int); values(double)...]. I
>>>>>>>> had to bitshift and cast two ints as a double in order to make that work
>>>>>>>> from a third-party OSC library outside Csound. It didn't seem right and
>>>>>>>> I don't think it's possible in every programming language.
>>>>>>>>
>>>>>>>> Cheers.
>>>>>>>>
>>>>>>>>
>>>>>>>> On 05/04/17 08:30, Victor Lazzarini wrote:
>>>>>>>>> Following our conclusion that liblo seems to be overly heavy weight for OSC sending, I have
>>>>>>>>> implemented an alternative version that uses UDP sockets directly. It is currently called
>>>>>>>>> OSCsend2 and the interface is exactly the same to OSCsend. In our tests, it appears to
>>>>>>>>> do the job, but have not tested it extensively.
>>>>>>>>>
>>>>>>>>> It has been suggested to remove OSCsend and replace it with OSCsend2, so I would
>>>>>>>>> like to check if OSCsend users could test OSCsend2 and let us know if there are differences
>>>>>>>>> and whether it works OK for you. We would also then like to know whether having
>>>>>>>>> OSCsend2 alongside OSCsend is your preference, or whether we should just replace it.
>>>>>>>>>
>>>>>>>>> ========================
>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>> Maynooth University,
>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>
>>>>>>>>> Csound mailing list
>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>> Send bugs reports to
>>>>>>>>>     https://github.com/csound/csound/issues
>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>> Csound mailing list
>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>> Send bugs reports to
>>>>>>>>     https://github.com/csound/csound/issues
>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>> Csound mailing list
>>>>>>> Csound@listserv.heanet.ie
>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>> Send bugs reports to
>>>>>>>      https://github.com/csound/csound/issues
>>>>>>> Discussions of bugs and features can be posted here
>>>>>> Csound mailing list
>>>>>> Csound@listserv.heanet.ie
>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>> Send bugs reports to
>>>>>>      https://github.com/csound/csound/issues
>>>>>> Discussions of bugs and features can be posted here
>>>>> Csound mailing list
>>>>> Csound@listserv.heanet.ie
>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>> Send bugs reports to
>>>>>       https://github.com/csound/csound/issues
>>>>> Discussions of bugs and features can be posted here
>>>> Csound mailing list
>>>> Csound@listserv.heanet.ie
>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>> Send bugs reports to
>>>>       https://github.com/csound/csound/issues
>>>> Discussions of bugs and features can be posted here
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>        https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>        https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

yes, same thing from the user perspective. Except that you can define how many dimensions you want
to hold the data in.
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 6 Apr 2017, at 21:33, Guillermo Senna  wrote:
> 
> I like that. Non of those characters are really part of the OSC
> specification, so why not?
> 
> But with this approach you would still use a Csound array as xdata1 in
> OSClisten, right?
> 
> On 06/04/17 17:16, Victor Lazzarini wrote:
>> We could put in a different type name for non-descript double-format data sequence (e.g. 2), for instance
>> call it “D”.
>> ========================
>> Prof. Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy,
>> Maynooth University,
>> Maynooth, Co Kildare, Ireland
>> Tel: 00 353 7086936
>> Fax: 00 353 1 7086952 
>> 
>>> On 6 Apr 2017, at 21:04, Guillermo Senna  wrote:
>>> 
>>> I've not considered number 2 before. How about adding an opcode later
>>> for joining 2d arrays into a single multidimensional? Would it be to
>>> difficult/inefficient to do that considering that in the end it's all
>>> about pointers?
>>> 
>>> I don't want to change and break it for others already using the current
>>> structure.
>>> 
>>> 
>>> On 05/04/17 18:12, Victor Lazzarini wrote:
>>>> I see what you mean. It’s possible to change it, there are two options:
>>>> 
>>>> 1) encode everything with doubles
>>>> 2) leave dim and size. The size of the blob is always there before the
>>>> data, so we can just use that. It will be then up to the user to interpret
>>>> the data as a 1,2,3 ,… dimensional array. The data is always stored
>>>> as a flat vector (e.g. row-column for 2-d).
>>>> 
>>>> if people want it changed, I can do it.
>>>> ========================
>>>> Prof. Victor Lazzarini
>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>> Maynooth University,
>>>> Maynooth, Co Kildare, Ireland
>>>> Tel: 00 353 7086936
>>>> Fax: 00 353 1 7086952 
>>>> 
>>>>> On 5 Apr 2017, at 18:24, Guillermo Senna  wrote:
>>>>> 
>>>>> My reasoning is that in the different programming languages you'd use a
>>>>> library/module for handling the OSC part and that would in turn have
>>>>> some abstraction for sending entire arrays as blobs. Now, Csound
>>>>> requests for two 32-bit ints and then the rest 64-bits doubles. Is that
>>>>> always possible to control in the higher-level languages?
>>>>> 
>>>>> Initially what I'd have thought is that I could build an array with all
>>>>> doubles and Csound would internally truncate the first two values and
>>>>> cast them into ints.
>>>>> 
>>>>> But if it's working for everyone right now nothing should be changed!
>>>>> 
>>>>> 
>>>>> On 05/04/17 14:04, Victor Lazzarini wrote:
>>>>>> Well, Csound reads two ints, as far as I can see. So I would expect that you can just send two
>>>>>> separate ints and Csound would understand it (first the dimension, then the size). This is
>>>>>> what OSCsend2 (& OSCsend) does. Not quite sure what might be going on at your end.
>>>>>> ========================
>>>>>> Prof. Victor Lazzarini
>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>> Maynooth University,
>>>>>> Maynooth, Co Kildare, Ireland
>>>>>> Tel: 00 353 7086936
>>>>>> Fax: 00 353 1 7086952 
>>>>>> 
>>>>>>> On 5 Apr 2017, at 17:44, Guillermo Senna  wrote:
>>>>>>> 
>>>>>>> Well I'm doing it in C++ with oscpack and for me it works. Now, I don't
>>>>>>> know much about python for example, but if you are using a python module
>>>>>>> for handling the OSC part of your program, is it possible to construct
>>>>>>> the array to be sent as two ints and the rest as doubles?
>>>>>>> 
>>>>>>> I'm asking from complete ignorance, Victor. It just seemed odd to
>>>>>>> (instead of passing my entire vector in C++) have to do something like this:
>>>>>>> 
>>>>>>> unsigned long ui = qvlist.size();
>>>>>>> ui <<= 32; ui |= 1;
>>>>>>> vec.push_back (*(double*)&ui);
>>>>>>> 
>>>>>>> 
>>>>>>> On 05/04/17 13:30, Victor Lazzarini wrote:
>>>>>>>> I have implemented the array, audio and function table as per OSCsend/OSClisten. As far as I can see from the code, the blob is as you
>>>>>>>> describe, all data being sent in the native endianess (little endian for i386/x86_64). It could be that the OSC lib is expecting the data
>>>>>>>> in big-endian ints, 4 bytes at a time. As far as I understand, the OSC should not impose any particular interpretation to the blob,
>>>>>>>> but just take it as a string of bytes.
>>>>>>>> 
>>>>>>>> ========================
>>>>>>>> Prof. Victor Lazzarini
>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>> Maynooth University,
>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>> Tel: 00 353 7086936
>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>> 
>>>>>>>>> On 5 Apr 2017, at 17:03, Guillermo Senna  wrote:
>>>>>>>>> 
>>>>>>>>> I'll try it in a few moments. Are you going to replace OSClisten too? If
>>>>>>>>> you do, please beware that right now receiving an array in Csound
>>>>>>>>> expects the structure [dimensions(int); size(int); values(double)...]. I
>>>>>>>>> had to bitshift and cast two ints as a double in order to make that work
>>>>>>>>> from a third-party OSC library outside Csound. It didn't seem right and
>>>>>>>>> I don't think it's possible in every programming language.
>>>>>>>>> 
>>>>>>>>> Cheers.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 05/04/17 08:30, Victor Lazzarini wrote:
>>>>>>>>>> Following our conclusion that liblo seems to be overly heavy weight for OSC sending, I have
>>>>>>>>>> implemented an alternative version that uses UDP sockets directly. It is currently called
>>>>>>>>>> OSCsend2 and the interface is exactly the same to OSCsend. In our tests, it appears to
>>>>>>>>>> do the job, but have not tested it extensively.
>>>>>>>>>> 
>>>>>>>>>> It has been suggested to remove OSCsend and replace it with OSCsend2, so I would
>>>>>>>>>> like to check if OSCsend users could test OSCsend2 and let us know if there are differences
>>>>>>>>>> and whether it works OK for you. We would also then like to know whether having
>>>>>>>>>> OSCsend2 alongside OSCsend is your preference, or whether we should just replace it.
>>>>>>>>>> 
>>>>>>>>>> ========================
>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>> Maynooth University,
>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>> 
>>>>>>>>>> Csound mailing list
>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>> Send bugs reports to
>>>>>>>>>>    https://github.com/csound/csound/issues
>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>> Csound mailing list
>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>> Send bugs reports to
>>>>>>>>>    https://github.com/csound/csound/issues
>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>> Csound mailing list
>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>> Send bugs reports to
>>>>>>>>     https://github.com/csound/csound/issues
>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>> Csound mailing list
>>>>>>> Csound@listserv.heanet.ie
>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>> Send bugs reports to
>>>>>>>     https://github.com/csound/csound/issues
>>>>>>> Discussions of bugs and features can be posted here
>>>>>> Csound mailing list
>>>>>> Csound@listserv.heanet.ie
>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>> Send bugs reports to
>>>>>>      https://github.com/csound/csound/issues
>>>>>> Discussions of bugs and features can be posted here
>>>>> Csound mailing list
>>>>> Csound@listserv.heanet.ie
>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>> Send bugs reports to
>>>>>      https://github.com/csound/csound/issues
>>>>> Discussions of bugs and features can be posted here
>>>> Csound mailing list
>>>> Csound@listserv.heanet.ie
>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>> Send bugs reports to
>>>>       https://github.com/csound/csound/issues
>>>> Discussions of bugs and features can be posted here
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>       https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>> 
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>        https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
> 
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here


Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I'm not so sure I follow you with that last sentence. Do you mean
something like this could be possible?

kArr[][] init 2, 16
kk1  OSClisten gihandle, "/multiArr", "DD", kArr[0], kArr[1]



On 06/04/17 17:36, Victor Lazzarini wrote:
> yes, same thing from the user perspective. Except that you can define how many dimensions you want
> to hold the data in.
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952 
>
>> On 6 Apr 2017, at 21:33, Guillermo Senna  wrote:
>>
>> I like that. Non of those characters are really part of the OSC
>> specification, so why not?
>>
>> But with this approach you would still use a Csound array as xdata1 in
>> OSClisten, right?
>>
>> On 06/04/17 17:16, Victor Lazzarini wrote:
>>> We could put in a different type name for non-descript double-format data sequence (e.g. 2), for instance
>>> call it “D”.
>>> ========================
>>> Prof. Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy,
>>> Maynooth University,
>>> Maynooth, Co Kildare, Ireland
>>> Tel: 00 353 7086936
>>> Fax: 00 353 1 7086952 
>>>
>>>> On 6 Apr 2017, at 21:04, Guillermo Senna  wrote:
>>>>
>>>> I've not considered number 2 before. How about adding an opcode later
>>>> for joining 2d arrays into a single multidimensional? Would it be to
>>>> difficult/inefficient to do that considering that in the end it's all
>>>> about pointers?
>>>>
>>>> I don't want to change and break it for others already using the current
>>>> structure.
>>>>
>>>>
>>>> On 05/04/17 18:12, Victor Lazzarini wrote:
>>>>> I see what you mean. It’s possible to change it, there are two options:
>>>>>
>>>>> 1) encode everything with doubles
>>>>> 2) leave dim and size. The size of the blob is always there before the
>>>>> data, so we can just use that. It will be then up to the user to interpret
>>>>> the data as a 1,2,3 ,… dimensional array. The data is always stored
>>>>> as a flat vector (e.g. row-column for 2-d).
>>>>>
>>>>> if people want it changed, I can do it.
>>>>> ========================
>>>>> Prof. Victor Lazzarini
>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>> Maynooth University,
>>>>> Maynooth, Co Kildare, Ireland
>>>>> Tel: 00 353 7086936
>>>>> Fax: 00 353 1 7086952 
>>>>>
>>>>>> On 5 Apr 2017, at 18:24, Guillermo Senna  wrote:
>>>>>>
>>>>>> My reasoning is that in the different programming languages you'd use a
>>>>>> library/module for handling the OSC part and that would in turn have
>>>>>> some abstraction for sending entire arrays as blobs. Now, Csound
>>>>>> requests for two 32-bit ints and then the rest 64-bits doubles. Is that
>>>>>> always possible to control in the higher-level languages?
>>>>>>
>>>>>> Initially what I'd have thought is that I could build an array with all
>>>>>> doubles and Csound would internally truncate the first two values and
>>>>>> cast them into ints.
>>>>>>
>>>>>> But if it's working for everyone right now nothing should be changed!
>>>>>>
>>>>>>
>>>>>> On 05/04/17 14:04, Victor Lazzarini wrote:
>>>>>>> Well, Csound reads two ints, as far as I can see. So I would expect that you can just send two
>>>>>>> separate ints and Csound would understand it (first the dimension, then the size). This is
>>>>>>> what OSCsend2 (& OSCsend) does. Not quite sure what might be going on at your end.
>>>>>>> ========================
>>>>>>> Prof. Victor Lazzarini
>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>> Maynooth University,
>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>> Tel: 00 353 7086936
>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>
>>>>>>>> On 5 Apr 2017, at 17:44, Guillermo Senna  wrote:
>>>>>>>>
>>>>>>>> Well I'm doing it in C++ with oscpack and for me it works. Now, I don't
>>>>>>>> know much about python for example, but if you are using a python module
>>>>>>>> for handling the OSC part of your program, is it possible to construct
>>>>>>>> the array to be sent as two ints and the rest as doubles?
>>>>>>>>
>>>>>>>> I'm asking from complete ignorance, Victor. It just seemed odd to
>>>>>>>> (instead of passing my entire vector in C++) have to do something like this:
>>>>>>>>
>>>>>>>> unsigned long ui = qvlist.size();
>>>>>>>> ui <<= 32; ui |= 1;
>>>>>>>> vec.push_back (*(double*)&ui);
>>>>>>>>
>>>>>>>>
>>>>>>>> On 05/04/17 13:30, Victor Lazzarini wrote:
>>>>>>>>> I have implemented the array, audio and function table as per OSCsend/OSClisten. As far as I can see from the code, the blob is as you
>>>>>>>>> describe, all data being sent in the native endianess (little endian for i386/x86_64). It could be that the OSC lib is expecting the data
>>>>>>>>> in big-endian ints, 4 bytes at a time. As far as I understand, the OSC should not impose any particular interpretation to the blob,
>>>>>>>>> but just take it as a string of bytes.
>>>>>>>>>
>>>>>>>>> ========================
>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>> Maynooth University,
>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>
>>>>>>>>>> On 5 Apr 2017, at 17:03, Guillermo Senna  wrote:
>>>>>>>>>>
>>>>>>>>>> I'll try it in a few moments. Are you going to replace OSClisten too? If
>>>>>>>>>> you do, please beware that right now receiving an array in Csound
>>>>>>>>>> expects the structure [dimensions(int); size(int); values(double)...]. I
>>>>>>>>>> had to bitshift and cast two ints as a double in order to make that work
>>>>>>>>>> from a third-party OSC library outside Csound. It didn't seem right and
>>>>>>>>>> I don't think it's possible in every programming language.
>>>>>>>>>>
>>>>>>>>>> Cheers.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 05/04/17 08:30, Victor Lazzarini wrote:
>>>>>>>>>>> Following our conclusion that liblo seems to be overly heavy weight for OSC sending, I have
>>>>>>>>>>> implemented an alternative version that uses UDP sockets directly. It is currently called
>>>>>>>>>>> OSCsend2 and the interface is exactly the same to OSCsend. In our tests, it appears to
>>>>>>>>>>> do the job, but have not tested it extensively.
>>>>>>>>>>>
>>>>>>>>>>> It has been suggested to remove OSCsend and replace it with OSCsend2, so I would
>>>>>>>>>>> like to check if OSCsend users could test OSCsend2 and let us know if there are differences
>>>>>>>>>>> and whether it works OK for you. We would also then like to know whether having
>>>>>>>>>>> OSCsend2 alongside OSCsend is your preference, or whether we should just replace it.
>>>>>>>>>>>
>>>>>>>>>>> ========================
>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>> Maynooth University,
>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>
>>>>>>>>>>> Csound mailing list
>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>    https://github.com/csound/csound/issues
>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>> Csound mailing list
>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>> Send bugs reports to
>>>>>>>>>>    https://github.com/csound/csound/issues
>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>> Csound mailing list
>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>> Send bugs reports to
>>>>>>>>>     https://github.com/csound/csound/issues
>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>> Csound mailing list
>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>> Send bugs reports to
>>>>>>>>     https://github.com/csound/csound/issues
>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>> Csound mailing list
>>>>>>> Csound@listserv.heanet.ie
>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>> Send bugs reports to
>>>>>>>      https://github.com/csound/csound/issues
>>>>>>> Discussions of bugs and features can be posted here
>>>>>> Csound mailing list
>>>>>> Csound@listserv.heanet.ie
>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>> Send bugs reports to
>>>>>>      https://github.com/csound/csound/issues
>>>>>> Discussions of bugs and features can be posted here
>>>>> Csound mailing list
>>>>> Csound@listserv.heanet.ie
>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>> Send bugs reports to
>>>>>       https://github.com/csound/csound/issues
>>>>> Discussions of bugs and features can be posted here
>>>> Csound mailing list
>>>> Csound@listserv.heanet.ie
>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>> Send bugs reports to
>>>>       https://github.com/csound/csound/issues
>>>> Discussions of bugs and features can be posted here
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>        https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>        https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

No, I mean

kArr[][] init 2, 16
kk1  OSClisten gihandle, "/multiArr", "D", kArr

or

kArr[] init 32
kk1  OSClisten gihandle, "/multiArr", "D", kArr

both working, the choice is yours


========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 6 Apr 2017, at 21:46, Guillermo Senna  wrote:
> 
> I'm not so sure I follow you with that last sentence. Do you mean
> something like this could be possible?
> 
> kArr[][] init 2, 16
> kk1  OSClisten gihandle, "/multiArr", "DD", kArr[0], kArr[1]
> 
> 
> 
> On 06/04/17 17:36, Victor Lazzarini wrote:
>> yes, same thing from the user perspective. Except that you can define how many dimensions you want
>> to hold the data in.
>> ========================
>> Prof. Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy,
>> Maynooth University,
>> Maynooth, Co Kildare, Ireland
>> Tel: 00 353 7086936
>> Fax: 00 353 1 7086952 
>> 
>>> On 6 Apr 2017, at 21:33, Guillermo Senna  wrote:
>>> 
>>> I like that. Non of those characters are really part of the OSC
>>> specification, so why not?
>>> 
>>> But with this approach you would still use a Csound array as xdata1 in
>>> OSClisten, right?
>>> 
>>> On 06/04/17 17:16, Victor Lazzarini wrote:
>>>> We could put in a different type name for non-descript double-format data sequence (e.g. 2), for instance
>>>> call it “D”.
>>>> ========================
>>>> Prof. Victor Lazzarini
>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>> Maynooth University,
>>>> Maynooth, Co Kildare, Ireland
>>>> Tel: 00 353 7086936
>>>> Fax: 00 353 1 7086952 
>>>> 
>>>>> On 6 Apr 2017, at 21:04, Guillermo Senna  wrote:
>>>>> 
>>>>> I've not considered number 2 before. How about adding an opcode later
>>>>> for joining 2d arrays into a single multidimensional? Would it be to
>>>>> difficult/inefficient to do that considering that in the end it's all
>>>>> about pointers?
>>>>> 
>>>>> I don't want to change and break it for others already using the current
>>>>> structure.
>>>>> 
>>>>> 
>>>>> On 05/04/17 18:12, Victor Lazzarini wrote:
>>>>>> I see what you mean. It’s possible to change it, there are two options:
>>>>>> 
>>>>>> 1) encode everything with doubles
>>>>>> 2) leave dim and size. The size of the blob is always there before the
>>>>>> data, so we can just use that. It will be then up to the user to interpret
>>>>>> the data as a 1,2,3 ,… dimensional array. The data is always stored
>>>>>> as a flat vector (e.g. row-column for 2-d).
>>>>>> 
>>>>>> if people want it changed, I can do it.
>>>>>> ========================
>>>>>> Prof. Victor Lazzarini
>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>> Maynooth University,
>>>>>> Maynooth, Co Kildare, Ireland
>>>>>> Tel: 00 353 7086936
>>>>>> Fax: 00 353 1 7086952 
>>>>>> 
>>>>>>> On 5 Apr 2017, at 18:24, Guillermo Senna  wrote:
>>>>>>> 
>>>>>>> My reasoning is that in the different programming languages you'd use a
>>>>>>> library/module for handling the OSC part and that would in turn have
>>>>>>> some abstraction for sending entire arrays as blobs. Now, Csound
>>>>>>> requests for two 32-bit ints and then the rest 64-bits doubles. Is that
>>>>>>> always possible to control in the higher-level languages?
>>>>>>> 
>>>>>>> Initially what I'd have thought is that I could build an array with all
>>>>>>> doubles and Csound would internally truncate the first two values and
>>>>>>> cast them into ints.
>>>>>>> 
>>>>>>> But if it's working for everyone right now nothing should be changed!
>>>>>>> 
>>>>>>> 
>>>>>>> On 05/04/17 14:04, Victor Lazzarini wrote:
>>>>>>>> Well, Csound reads two ints, as far as I can see. So I would expect that you can just send two
>>>>>>>> separate ints and Csound would understand it (first the dimension, then the size). This is
>>>>>>>> what OSCsend2 (& OSCsend) does. Not quite sure what might be going on at your end.
>>>>>>>> ========================
>>>>>>>> Prof. Victor Lazzarini
>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>> Maynooth University,
>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>> Tel: 00 353 7086936
>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>> 
>>>>>>>>> On 5 Apr 2017, at 17:44, Guillermo Senna  wrote:
>>>>>>>>> 
>>>>>>>>> Well I'm doing it in C++ with oscpack and for me it works. Now, I don't
>>>>>>>>> know much about python for example, but if you are using a python module
>>>>>>>>> for handling the OSC part of your program, is it possible to construct
>>>>>>>>> the array to be sent as two ints and the rest as doubles?
>>>>>>>>> 
>>>>>>>>> I'm asking from complete ignorance, Victor. It just seemed odd to
>>>>>>>>> (instead of passing my entire vector in C++) have to do something like this:
>>>>>>>>> 
>>>>>>>>> unsigned long ui = qvlist.size();
>>>>>>>>> ui <<= 32; ui |= 1;
>>>>>>>>> vec.push_back (*(double*)&ui);
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 05/04/17 13:30, Victor Lazzarini wrote:
>>>>>>>>>> I have implemented the array, audio and function table as per OSCsend/OSClisten. As far as I can see from the code, the blob is as you
>>>>>>>>>> describe, all data being sent in the native endianess (little endian for i386/x86_64). It could be that the OSC lib is expecting the data
>>>>>>>>>> in big-endian ints, 4 bytes at a time. As far as I understand, the OSC should not impose any particular interpretation to the blob,
>>>>>>>>>> but just take it as a string of bytes.
>>>>>>>>>> 
>>>>>>>>>> ========================
>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>> Maynooth University,
>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>> 
>>>>>>>>>>> On 5 Apr 2017, at 17:03, Guillermo Senna  wrote:
>>>>>>>>>>> 
>>>>>>>>>>> I'll try it in a few moments. Are you going to replace OSClisten too? If
>>>>>>>>>>> you do, please beware that right now receiving an array in Csound
>>>>>>>>>>> expects the structure [dimensions(int); size(int); values(double)...]. I
>>>>>>>>>>> had to bitshift and cast two ints as a double in order to make that work
>>>>>>>>>>> from a third-party OSC library outside Csound. It didn't seem right and
>>>>>>>>>>> I don't think it's possible in every programming language.
>>>>>>>>>>> 
>>>>>>>>>>> Cheers.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On 05/04/17 08:30, Victor Lazzarini wrote:
>>>>>>>>>>>> Following our conclusion that liblo seems to be overly heavy weight for OSC sending, I have
>>>>>>>>>>>> implemented an alternative version that uses UDP sockets directly. It is currently called
>>>>>>>>>>>> OSCsend2 and the interface is exactly the same to OSCsend. In our tests, it appears to
>>>>>>>>>>>> do the job, but have not tested it extensively.
>>>>>>>>>>>> 
>>>>>>>>>>>> It has been suggested to remove OSCsend and replace it with OSCsend2, so I would
>>>>>>>>>>>> like to check if OSCsend users could test OSCsend2 and let us know if there are differences
>>>>>>>>>>>> and whether it works OK for you. We would also then like to know whether having
>>>>>>>>>>>> OSCsend2 alongside OSCsend is your preference, or whether we should just replace it.
>>>>>>>>>>>> 
>>>>>>>>>>>> ========================
>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>> 
>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>   https://github.com/csound/csound/issues
>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>> Csound mailing list
>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>   https://github.com/csound/csound/issues
>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>> Csound mailing list
>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>> Send bugs reports to
>>>>>>>>>>    https://github.com/csound/csound/issues
>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>> Csound mailing list
>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>> Send bugs reports to
>>>>>>>>>    https://github.com/csound/csound/issues
>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>> Csound mailing list
>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>> Send bugs reports to
>>>>>>>>     https://github.com/csound/csound/issues
>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>> Csound mailing list
>>>>>>> Csound@listserv.heanet.ie
>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>> Send bugs reports to
>>>>>>>     https://github.com/csound/csound/issues
>>>>>>> Discussions of bugs and features can be posted here
>>>>>> Csound mailing list
>>>>>> Csound@listserv.heanet.ie
>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>> Send bugs reports to
>>>>>>      https://github.com/csound/csound/issues
>>>>>> Discussions of bugs and features can be posted here
>>>>> Csound mailing list
>>>>> Csound@listserv.heanet.ie
>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>> Send bugs reports to
>>>>>      https://github.com/csound/csound/issues
>>>>> Discussions of bugs and features can be posted here
>>>> Csound mailing list
>>>> Csound@listserv.heanet.ie
>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>> Send bugs reports to
>>>>       https://github.com/csound/csound/issues
>>>> Discussions of bugs and features can be posted here
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>       https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>> 
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>        https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
> 
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here


Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Oh, I see. And in the 2D version, if I send a single blob/array with:

10 elements -> they all end up in dimension no. 1

30 elements -> they'd go 16-14

40 elements -> 16-24

Or is it going to be an error not to match the dimensions/sizes?

On 06/04/17 18:10, Victor Lazzarini wrote:
> No, I mean
>
> kArr[][] init 2, 16
> kk1  OSClisten gihandle, "/multiArr", "D", kArr
>
> or
>
> kArr[] init 32
> kk1  OSClisten gihandle, "/multiArr", "D", kArr
>
> both working, the choice is yours
>
>
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952 
>
>> On 6 Apr 2017, at 21:46, Guillermo Senna  wrote:
>>
>> I'm not so sure I follow you with that last sentence. Do you mean
>> something like this could be possible?
>>
>> kArr[][] init 2, 16
>> kk1  OSClisten gihandle, "/multiArr", "DD", kArr[0], kArr[1]
>>
>>
>>
>> On 06/04/17 17:36, Victor Lazzarini wrote:
>>> yes, same thing from the user perspective. Except that you can define how many dimensions you want
>>> to hold the data in.
>>> ========================
>>> Prof. Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy,
>>> Maynooth University,
>>> Maynooth, Co Kildare, Ireland
>>> Tel: 00 353 7086936
>>> Fax: 00 353 1 7086952 
>>>
>>>> On 6 Apr 2017, at 21:33, Guillermo Senna  wrote:
>>>>
>>>> I like that. Non of those characters are really part of the OSC
>>>> specification, so why not?
>>>>
>>>> But with this approach you would still use a Csound array as xdata1 in
>>>> OSClisten, right?
>>>>
>>>> On 06/04/17 17:16, Victor Lazzarini wrote:
>>>>> We could put in a different type name for non-descript double-format data sequence (e.g. 2), for instance
>>>>> call it “D”.
>>>>> ========================
>>>>> Prof. Victor Lazzarini
>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>> Maynooth University,
>>>>> Maynooth, Co Kildare, Ireland
>>>>> Tel: 00 353 7086936
>>>>> Fax: 00 353 1 7086952 
>>>>>
>>>>>> On 6 Apr 2017, at 21:04, Guillermo Senna  wrote:
>>>>>>
>>>>>> I've not considered number 2 before. How about adding an opcode later
>>>>>> for joining 2d arrays into a single multidimensional? Would it be to
>>>>>> difficult/inefficient to do that considering that in the end it's all
>>>>>> about pointers?
>>>>>>
>>>>>> I don't want to change and break it for others already using the current
>>>>>> structure.
>>>>>>
>>>>>>
>>>>>> On 05/04/17 18:12, Victor Lazzarini wrote:
>>>>>>> I see what you mean. It’s possible to change it, there are two options:
>>>>>>>
>>>>>>> 1) encode everything with doubles
>>>>>>> 2) leave dim and size. The size of the blob is always there before the
>>>>>>> data, so we can just use that. It will be then up to the user to interpret
>>>>>>> the data as a 1,2,3 ,… dimensional array. The data is always stored
>>>>>>> as a flat vector (e.g. row-column for 2-d).
>>>>>>>
>>>>>>> if people want it changed, I can do it.
>>>>>>> ========================
>>>>>>> Prof. Victor Lazzarini
>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>> Maynooth University,
>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>> Tel: 00 353 7086936
>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>
>>>>>>>> On 5 Apr 2017, at 18:24, Guillermo Senna  wrote:
>>>>>>>>
>>>>>>>> My reasoning is that in the different programming languages you'd use a
>>>>>>>> library/module for handling the OSC part and that would in turn have
>>>>>>>> some abstraction for sending entire arrays as blobs. Now, Csound
>>>>>>>> requests for two 32-bit ints and then the rest 64-bits doubles. Is that
>>>>>>>> always possible to control in the higher-level languages?
>>>>>>>>
>>>>>>>> Initially what I'd have thought is that I could build an array with all
>>>>>>>> doubles and Csound would internally truncate the first two values and
>>>>>>>> cast them into ints.
>>>>>>>>
>>>>>>>> But if it's working for everyone right now nothing should be changed!
>>>>>>>>
>>>>>>>>
>>>>>>>> On 05/04/17 14:04, Victor Lazzarini wrote:
>>>>>>>>> Well, Csound reads two ints, as far as I can see. So I would expect that you can just send two
>>>>>>>>> separate ints and Csound would understand it (first the dimension, then the size). This is
>>>>>>>>> what OSCsend2 (& OSCsend) does. Not quite sure what might be going on at your end.
>>>>>>>>> ========================
>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>> Maynooth University,
>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>
>>>>>>>>>> On 5 Apr 2017, at 17:44, Guillermo Senna  wrote:
>>>>>>>>>>
>>>>>>>>>> Well I'm doing it in C++ with oscpack and for me it works. Now, I don't
>>>>>>>>>> know much about python for example, but if you are using a python module
>>>>>>>>>> for handling the OSC part of your program, is it possible to construct
>>>>>>>>>> the array to be sent as two ints and the rest as doubles?
>>>>>>>>>>
>>>>>>>>>> I'm asking from complete ignorance, Victor. It just seemed odd to
>>>>>>>>>> (instead of passing my entire vector in C++) have to do something like this:
>>>>>>>>>>
>>>>>>>>>> unsigned long ui = qvlist.size();
>>>>>>>>>> ui <<= 32; ui |= 1;
>>>>>>>>>> vec.push_back (*(double*)&ui);
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 05/04/17 13:30, Victor Lazzarini wrote:
>>>>>>>>>>> I have implemented the array, audio and function table as per OSCsend/OSClisten. As far as I can see from the code, the blob is as you
>>>>>>>>>>> describe, all data being sent in the native endianess (little endian for i386/x86_64). It could be that the OSC lib is expecting the data
>>>>>>>>>>> in big-endian ints, 4 bytes at a time. As far as I understand, the OSC should not impose any particular interpretation to the blob,
>>>>>>>>>>> but just take it as a string of bytes.
>>>>>>>>>>>
>>>>>>>>>>> ========================
>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>> Maynooth University,
>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>
>>>>>>>>>>>> On 5 Apr 2017, at 17:03, Guillermo Senna  wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> I'll try it in a few moments. Are you going to replace OSClisten too? If
>>>>>>>>>>>> you do, please beware that right now receiving an array in Csound
>>>>>>>>>>>> expects the structure [dimensions(int); size(int); values(double)...]. I
>>>>>>>>>>>> had to bitshift and cast two ints as a double in order to make that work
>>>>>>>>>>>> from a third-party OSC library outside Csound. It didn't seem right and
>>>>>>>>>>>> I don't think it's possible in every programming language.
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 05/04/17 08:30, Victor Lazzarini wrote:
>>>>>>>>>>>>> Following our conclusion that liblo seems to be overly heavy weight for OSC sending, I have
>>>>>>>>>>>>> implemented an alternative version that uses UDP sockets directly. It is currently called
>>>>>>>>>>>>> OSCsend2 and the interface is exactly the same to OSCsend. In our tests, it appears to
>>>>>>>>>>>>> do the job, but have not tested it extensively.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It has been suggested to remove OSCsend and replace it with OSCsend2, so I would
>>>>>>>>>>>>> like to check if OSCsend users could test OSCsend2 and let us know if there are differences
>>>>>>>>>>>>> and whether it works OK for you. We would also then like to know whether having
>>>>>>>>>>>>> OSCsend2 alongside OSCsend is your preference, or whether we should just replace it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> ========================
>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>
>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>   https://github.com/csound/csound/issues
>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>   https://github.com/csound/csound/issues
>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>> Csound mailing list
>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>    https://github.com/csound/csound/issues
>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>> Csound mailing list
>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>> Send bugs reports to
>>>>>>>>>>    https://github.com/csound/csound/issues
>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>> Csound mailing list
>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>> Send bugs reports to
>>>>>>>>>     https://github.com/csound/csound/issues
>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>> Csound mailing list
>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>> Send bugs reports to
>>>>>>>>     https://github.com/csound/csound/issues
>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>> Csound mailing list
>>>>>>> Csound@listserv.heanet.ie
>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>> Send bugs reports to
>>>>>>>      https://github.com/csound/csound/issues
>>>>>>> Discussions of bugs and features can be posted here
>>>>>> Csound mailing list
>>>>>> Csound@listserv.heanet.ie
>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>> Send bugs reports to
>>>>>>      https://github.com/csound/csound/issues
>>>>>> Discussions of bugs and features can be posted here
>>>>> Csound mailing list
>>>>> Csound@listserv.heanet.ie
>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>> Send bugs reports to
>>>>>       https://github.com/csound/csound/issues
>>>>> Discussions of bugs and features can be posted here
>>>> Csound mailing list
>>>> Csound@listserv.heanet.ie
>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>> Send bugs reports to
>>>>       https://github.com/csound/csound/issues
>>>> Discussions of bugs and features can be posted here
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>        https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>        https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Say you send 10 elements.

You can interpret this as

[1,2,3,4,5,6,7,8,9,10]

or

[1,2]
[3,4]
[5,6]
[7,8]

or

[1,2,3,4,5]
[6,7,8,9,10]

or

[1,2,3]
[4,5,6]
[7,8,9]
[10,0,0]

etc

Whatever you do, if there isn’t enough size, the array grows dynamically. In the last
example there was more than enough size, but we only copied  the 10 numbers
we got.

I have added this type to OSClisten  and OSCsend2. 

========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 6 Apr 2017, at 22:20, Guillermo Senna  wrote:
> 
> Oh, I see. And in the 2D version, if I send a single blob/array with:
> 
> 10 elements -> they all end up in dimension no. 1
> 
> 30 elements -> they'd go 16-14
> 
> 40 elements -> 16-24
> 
> Or is it going to be an error not to match the dimensions/sizes?
> 
> On 06/04/17 18:10, Victor Lazzarini wrote:
>> No, I mean
>> 
>> kArr[][] init 2, 16
>> kk1  OSClisten gihandle, "/multiArr", "D", kArr
>> 
>> or
>> 
>> kArr[] init 32
>> kk1  OSClisten gihandle, "/multiArr", "D", kArr
>> 
>> both working, the choice is yours
>> 
>> 
>> ========================
>> Prof. Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy,
>> Maynooth University,
>> Maynooth, Co Kildare, Ireland
>> Tel: 00 353 7086936
>> Fax: 00 353 1 7086952 
>> 
>>> On 6 Apr 2017, at 21:46, Guillermo Senna  wrote:
>>> 
>>> I'm not so sure I follow you with that last sentence. Do you mean
>>> something like this could be possible?
>>> 
>>> kArr[][] init 2, 16
>>> kk1  OSClisten gihandle, "/multiArr", "DD", kArr[0], kArr[1]
>>> 
>>> 
>>> 
>>> On 06/04/17 17:36, Victor Lazzarini wrote:
>>>> yes, same thing from the user perspective. Except that you can define how many dimensions you want
>>>> to hold the data in.
>>>> ========================
>>>> Prof. Victor Lazzarini
>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>> Maynooth University,
>>>> Maynooth, Co Kildare, Ireland
>>>> Tel: 00 353 7086936
>>>> Fax: 00 353 1 7086952 
>>>> 
>>>>> On 6 Apr 2017, at 21:33, Guillermo Senna  wrote:
>>>>> 
>>>>> I like that. Non of those characters are really part of the OSC
>>>>> specification, so why not?
>>>>> 
>>>>> But with this approach you would still use a Csound array as xdata1 in
>>>>> OSClisten, right?
>>>>> 
>>>>> On 06/04/17 17:16, Victor Lazzarini wrote:
>>>>>> We could put in a different type name for non-descript double-format data sequence (e.g. 2), for instance
>>>>>> call it “D”.
>>>>>> ========================
>>>>>> Prof. Victor Lazzarini
>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>> Maynooth University,
>>>>>> Maynooth, Co Kildare, Ireland
>>>>>> Tel: 00 353 7086936
>>>>>> Fax: 00 353 1 7086952 
>>>>>> 
>>>>>>> On 6 Apr 2017, at 21:04, Guillermo Senna  wrote:
>>>>>>> 
>>>>>>> I've not considered number 2 before. How about adding an opcode later
>>>>>>> for joining 2d arrays into a single multidimensional? Would it be to
>>>>>>> difficult/inefficient to do that considering that in the end it's all
>>>>>>> about pointers?
>>>>>>> 
>>>>>>> I don't want to change and break it for others already using the current
>>>>>>> structure.
>>>>>>> 
>>>>>>> 
>>>>>>> On 05/04/17 18:12, Victor Lazzarini wrote:
>>>>>>>> I see what you mean. It’s possible to change it, there are two options:
>>>>>>>> 
>>>>>>>> 1) encode everything with doubles
>>>>>>>> 2) leave dim and size. The size of the blob is always there before the
>>>>>>>> data, so we can just use that. It will be then up to the user to interpret
>>>>>>>> the data as a 1,2,3 ,… dimensional array. The data is always stored
>>>>>>>> as a flat vector (e.g. row-column for 2-d).
>>>>>>>> 
>>>>>>>> if people want it changed, I can do it.
>>>>>>>> ========================
>>>>>>>> Prof. Victor Lazzarini
>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>> Maynooth University,
>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>> Tel: 00 353 7086936
>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>> 
>>>>>>>>> On 5 Apr 2017, at 18:24, Guillermo Senna  wrote:
>>>>>>>>> 
>>>>>>>>> My reasoning is that in the different programming languages you'd use a
>>>>>>>>> library/module for handling the OSC part and that would in turn have
>>>>>>>>> some abstraction for sending entire arrays as blobs. Now, Csound
>>>>>>>>> requests for two 32-bit ints and then the rest 64-bits doubles. Is that
>>>>>>>>> always possible to control in the higher-level languages?
>>>>>>>>> 
>>>>>>>>> Initially what I'd have thought is that I could build an array with all
>>>>>>>>> doubles and Csound would internally truncate the first two values and
>>>>>>>>> cast them into ints.
>>>>>>>>> 
>>>>>>>>> But if it's working for everyone right now nothing should be changed!
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 05/04/17 14:04, Victor Lazzarini wrote:
>>>>>>>>>> Well, Csound reads two ints, as far as I can see. So I would expect that you can just send two
>>>>>>>>>> separate ints and Csound would understand it (first the dimension, then the size). This is
>>>>>>>>>> what OSCsend2 (& OSCsend) does. Not quite sure what might be going on at your end.
>>>>>>>>>> ========================
>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>> Maynooth University,
>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>> 
>>>>>>>>>>> On 5 Apr 2017, at 17:44, Guillermo Senna  wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Well I'm doing it in C++ with oscpack and for me it works. Now, I don't
>>>>>>>>>>> know much about python for example, but if you are using a python module
>>>>>>>>>>> for handling the OSC part of your program, is it possible to construct
>>>>>>>>>>> the array to be sent as two ints and the rest as doubles?
>>>>>>>>>>> 
>>>>>>>>>>> I'm asking from complete ignorance, Victor. It just seemed odd to
>>>>>>>>>>> (instead of passing my entire vector in C++) have to do something like this:
>>>>>>>>>>> 
>>>>>>>>>>> unsigned long ui = qvlist.size();
>>>>>>>>>>> ui <<= 32; ui |= 1;
>>>>>>>>>>> vec.push_back (*(double*)&ui);
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On 05/04/17 13:30, Victor Lazzarini wrote:
>>>>>>>>>>>> I have implemented the array, audio and function table as per OSCsend/OSClisten. As far as I can see from the code, the blob is as you
>>>>>>>>>>>> describe, all data being sent in the native endianess (little endian for i386/x86_64). It could be that the OSC lib is expecting the data
>>>>>>>>>>>> in big-endian ints, 4 bytes at a time. As far as I understand, the OSC should not impose any particular interpretation to the blob,
>>>>>>>>>>>> but just take it as a string of bytes.
>>>>>>>>>>>> 
>>>>>>>>>>>> ========================
>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>> 
>>>>>>>>>>>>> On 5 Apr 2017, at 17:03, Guillermo Senna  wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I'll try it in a few moments. Are you going to replace OSClisten too? If
>>>>>>>>>>>>> you do, please beware that right now receiving an array in Csound
>>>>>>>>>>>>> expects the structure [dimensions(int); size(int); values(double)...]. I
>>>>>>>>>>>>> had to bitshift and cast two ints as a double in order to make that work
>>>>>>>>>>>>> from a third-party OSC library outside Csound. It didn't seem right and
>>>>>>>>>>>>> I don't think it's possible in every programming language.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Cheers.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On 05/04/17 08:30, Victor Lazzarini wrote:
>>>>>>>>>>>>>> Following our conclusion that liblo seems to be overly heavy weight for OSC sending, I have
>>>>>>>>>>>>>> implemented an alternative version that uses UDP sockets directly. It is currently called
>>>>>>>>>>>>>> OSCsend2 and the interface is exactly the same to OSCsend. In our tests, it appears to
>>>>>>>>>>>>>> do the job, but have not tested it extensively.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> It has been suggested to remove OSCsend and replace it with OSCsend2, so I would
>>>>>>>>>>>>>> like to check if OSCsend users could test OSCsend2 and let us know if there are differences
>>>>>>>>>>>>>> and whether it works OK for you. We would also then like to know whether having
>>>>>>>>>>>>>> OSCsend2 alongside OSCsend is your preference, or whether we should just replace it.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>  https://github.com/csound/csound/issues
>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>  https://github.com/csound/csound/issues
>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>   https://github.com/csound/csound/issues
>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>> Csound mailing list
>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>   https://github.com/csound/csound/issues
>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>> Csound mailing list
>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>> Send bugs reports to
>>>>>>>>>>    https://github.com/csound/csound/issues
>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>> Csound mailing list
>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>> Send bugs reports to
>>>>>>>>>    https://github.com/csound/csound/issues
>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>> Csound mailing list
>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>> Send bugs reports to
>>>>>>>>     https://github.com/csound/csound/issues
>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>> Csound mailing list
>>>>>>> Csound@listserv.heanet.ie
>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>> Send bugs reports to
>>>>>>>     https://github.com/csound/csound/issues
>>>>>>> Discussions of bugs and features can be posted here
>>>>>> Csound mailing list
>>>>>> Csound@listserv.heanet.ie
>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>> Send bugs reports to
>>>>>>      https://github.com/csound/csound/issues
>>>>>> Discussions of bugs and features can be posted here
>>>>> Csound mailing list
>>>>> Csound@listserv.heanet.ie
>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>> Send bugs reports to
>>>>>      https://github.com/csound/csound/issues
>>>>> Discussions of bugs and features can be posted here
>>>> Csound mailing list
>>>> Csound@listserv.heanet.ie
>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>> Send bugs reports to
>>>>       https://github.com/csound/csound/issues
>>>> Discussions of bugs and features can be posted here
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>       https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>> 
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>        https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
> 
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here


Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I tested the new specifier from outside Csound. Now I understand what
you mean Victor. The good thing is that it forces you to choose a common
size between sender and receiver in advance and that prevents you from
getting "osc::OutOfBufferMemoryException" while sending exceedingly
large vectors. The bad thing is the need to process the received array
and look for a delimiter while sending variable-sized arrays like I'm
doing. Or maybe I can just send the size before through "/kArrSize" or
something like that.

Just for the record, with the "A" specifier you can do "kArr[] init 1"
and the array will still grow and shrink dynamically according to
dimensions/sizes received. That is very convenient. With the "D"
specifier you get "Array index 2 out of range (0,0) for dimension 1".

I've to think now how to effectively process the received the array, but
I think you saved me from a difficult-to-diagnose bug that I'd probably
have encountered in the future because of the UDP protocol.

I'll test OSCsend2 now. Cheers.


On 06/04/17 18:33, Victor Lazzarini wrote:
> Say you send 10 elements.
>
> You can interpret this as
>
> [1,2,3,4,5,6,7,8,9,10]
>
> or
>
> [1,2]
> [3,4]
> [5,6]
> [7,8]
>
> or
>
> [1,2,3,4,5]
> [6,7,8,9,10]
>
> or
>
> [1,2,3]
> [4,5,6]
> [7,8,9]
> [10,0,0]
>
> etc
>
> Whatever you do, if there isn’t enough size, the array grows dynamically. In the last
> example there was more than enough size, but we only copied  the 10 numbers
> we got.
>
> I have added this type to OSClisten  and OSCsend2. 
>
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952 
>
>> On 6 Apr 2017, at 22:20, Guillermo Senna  wrote:
>>
>> Oh, I see. And in the 2D version, if I send a single blob/array with:
>>
>> 10 elements -> they all end up in dimension no. 1
>>
>> 30 elements -> they'd go 16-14
>>
>> 40 elements -> 16-24
>>
>> Or is it going to be an error not to match the dimensions/sizes?
>>
>> On 06/04/17 18:10, Victor Lazzarini wrote:
>>> No, I mean
>>>
>>> kArr[][] init 2, 16
>>> kk1  OSClisten gihandle, "/multiArr", "D", kArr
>>>
>>> or
>>>
>>> kArr[] init 32
>>> kk1  OSClisten gihandle, "/multiArr", "D", kArr
>>>
>>> both working, the choice is yours
>>>
>>>
>>> ========================
>>> Prof. Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy,
>>> Maynooth University,
>>> Maynooth, Co Kildare, Ireland
>>> Tel: 00 353 7086936
>>> Fax: 00 353 1 7086952 
>>>
>>>> On 6 Apr 2017, at 21:46, Guillermo Senna  wrote:
>>>>
>>>> I'm not so sure I follow you with that last sentence. Do you mean
>>>> something like this could be possible?
>>>>
>>>> kArr[][] init 2, 16
>>>> kk1  OSClisten gihandle, "/multiArr", "DD", kArr[0], kArr[1]
>>>>
>>>>
>>>>
>>>> On 06/04/17 17:36, Victor Lazzarini wrote:
>>>>> yes, same thing from the user perspective. Except that you can define how many dimensions you want
>>>>> to hold the data in.
>>>>> ========================
>>>>> Prof. Victor Lazzarini
>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>> Maynooth University,
>>>>> Maynooth, Co Kildare, Ireland
>>>>> Tel: 00 353 7086936
>>>>> Fax: 00 353 1 7086952 
>>>>>
>>>>>> On 6 Apr 2017, at 21:33, Guillermo Senna  wrote:
>>>>>>
>>>>>> I like that. Non of those characters are really part of the OSC
>>>>>> specification, so why not?
>>>>>>
>>>>>> But with this approach you would still use a Csound array as xdata1 in
>>>>>> OSClisten, right?
>>>>>>
>>>>>> On 06/04/17 17:16, Victor Lazzarini wrote:
>>>>>>> We could put in a different type name for non-descript double-format data sequence (e.g. 2), for instance
>>>>>>> call it “D”.
>>>>>>> ========================
>>>>>>> Prof. Victor Lazzarini
>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>> Maynooth University,
>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>> Tel: 00 353 7086936
>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>
>>>>>>>> On 6 Apr 2017, at 21:04, Guillermo Senna  wrote:
>>>>>>>>
>>>>>>>> I've not considered number 2 before. How about adding an opcode later
>>>>>>>> for joining 2d arrays into a single multidimensional? Would it be to
>>>>>>>> difficult/inefficient to do that considering that in the end it's all
>>>>>>>> about pointers?
>>>>>>>>
>>>>>>>> I don't want to change and break it for others already using the current
>>>>>>>> structure.
>>>>>>>>
>>>>>>>>
>>>>>>>> On 05/04/17 18:12, Victor Lazzarini wrote:
>>>>>>>>> I see what you mean. It’s possible to change it, there are two options:
>>>>>>>>>
>>>>>>>>> 1) encode everything with doubles
>>>>>>>>> 2) leave dim and size. The size of the blob is always there before the
>>>>>>>>> data, so we can just use that. It will be then up to the user to interpret
>>>>>>>>> the data as a 1,2,3 ,… dimensional array. The data is always stored
>>>>>>>>> as a flat vector (e.g. row-column for 2-d).
>>>>>>>>>
>>>>>>>>> if people want it changed, I can do it.
>>>>>>>>> ========================
>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>> Maynooth University,
>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>
>>>>>>>>>> On 5 Apr 2017, at 18:24, Guillermo Senna  wrote:
>>>>>>>>>>
>>>>>>>>>> My reasoning is that in the different programming languages you'd use a
>>>>>>>>>> library/module for handling the OSC part and that would in turn have
>>>>>>>>>> some abstraction for sending entire arrays as blobs. Now, Csound
>>>>>>>>>> requests for two 32-bit ints and then the rest 64-bits doubles. Is that
>>>>>>>>>> always possible to control in the higher-level languages?
>>>>>>>>>>
>>>>>>>>>> Initially what I'd have thought is that I could build an array with all
>>>>>>>>>> doubles and Csound would internally truncate the first two values and
>>>>>>>>>> cast them into ints.
>>>>>>>>>>
>>>>>>>>>> But if it's working for everyone right now nothing should be changed!
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 05/04/17 14:04, Victor Lazzarini wrote:
>>>>>>>>>>> Well, Csound reads two ints, as far as I can see. So I would expect that you can just send two
>>>>>>>>>>> separate ints and Csound would understand it (first the dimension, then the size). This is
>>>>>>>>>>> what OSCsend2 (& OSCsend) does. Not quite sure what might be going on at your end.
>>>>>>>>>>> ========================
>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>> Maynooth University,
>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>
>>>>>>>>>>>> On 5 Apr 2017, at 17:44, Guillermo Senna  wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Well I'm doing it in C++ with oscpack and for me it works. Now, I don't
>>>>>>>>>>>> know much about python for example, but if you are using a python module
>>>>>>>>>>>> for handling the OSC part of your program, is it possible to construct
>>>>>>>>>>>> the array to be sent as two ints and the rest as doubles?
>>>>>>>>>>>>
>>>>>>>>>>>> I'm asking from complete ignorance, Victor. It just seemed odd to
>>>>>>>>>>>> (instead of passing my entire vector in C++) have to do something like this:
>>>>>>>>>>>>
>>>>>>>>>>>> unsigned long ui = qvlist.size();
>>>>>>>>>>>> ui <<= 32; ui |= 1;
>>>>>>>>>>>> vec.push_back (*(double*)&ui);
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 05/04/17 13:30, Victor Lazzarini wrote:
>>>>>>>>>>>>> I have implemented the array, audio and function table as per OSCsend/OSClisten. As far as I can see from the code, the blob is as you
>>>>>>>>>>>>> describe, all data being sent in the native endianess (little endian for i386/x86_64). It could be that the OSC lib is expecting the data
>>>>>>>>>>>>> in big-endian ints, 4 bytes at a time. As far as I understand, the OSC should not impose any particular interpretation to the blob,
>>>>>>>>>>>>> but just take it as a string of bytes.
>>>>>>>>>>>>>
>>>>>>>>>>>>> ========================
>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 5 Apr 2017, at 17:03, Guillermo Senna  wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'll try it in a few moments. Are you going to replace OSClisten too? If
>>>>>>>>>>>>>> you do, please beware that right now receiving an array in Csound
>>>>>>>>>>>>>> expects the structure [dimensions(int); size(int); values(double)...]. I
>>>>>>>>>>>>>> had to bitshift and cast two ints as a double in order to make that work
>>>>>>>>>>>>>> from a third-party OSC library outside Csound. It didn't seem right and
>>>>>>>>>>>>>> I don't think it's possible in every programming language.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Cheers.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 05/04/17 08:30, Victor Lazzarini wrote:
>>>>>>>>>>>>>>> Following our conclusion that liblo seems to be overly heavy weight for OSC sending, I have
>>>>>>>>>>>>>>> implemented an alternative version that uses UDP sockets directly. It is currently called
>>>>>>>>>>>>>>> OSCsend2 and the interface is exactly the same to OSCsend. In our tests, it appears to
>>>>>>>>>>>>>>> do the job, but have not tested it extensively.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It has been suggested to remove OSCsend and replace it with OSCsend2, so I would
>>>>>>>>>>>>>>> like to check if OSCsend users could test OSCsend2 and let us know if there are differences
>>>>>>>>>>>>>>> and whether it works OK for you. We would also then like to know whether having
>>>>>>>>>>>>>>> OSCsend2 alongside OSCsend is your preference, or whether we should just replace it.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>  https://github.com/csound/csound/issues
>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>  https://github.com/csound/csound/issues
>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>   https://github.com/csound/csound/issues
>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>   https://github.com/csound/csound/issues
>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>> Csound mailing list
>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>    https://github.com/csound/csound/issues
>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>> Csound mailing list
>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>> Send bugs reports to
>>>>>>>>>>    https://github.com/csound/csound/issues
>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>> Csound mailing list
>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>> Send bugs reports to
>>>>>>>>>     https://github.com/csound/csound/issues
>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>> Csound mailing list
>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>> Send bugs reports to
>>>>>>>>     https://github.com/csound/csound/issues
>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>> Csound mailing list
>>>>>>> Csound@listserv.heanet.ie
>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>> Send bugs reports to
>>>>>>>      https://github.com/csound/csound/issues
>>>>>>> Discussions of bugs and features can be posted here
>>>>>> Csound mailing list
>>>>>> Csound@listserv.heanet.ie
>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>> Send bugs reports to
>>>>>>      https://github.com/csound/csound/issues
>>>>>> Discussions of bugs and features can be posted here
>>>>> Csound mailing list
>>>>> Csound@listserv.heanet.ie
>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>> Send bugs reports to
>>>>>       https://github.com/csound/csound/issues
>>>>> Discussions of bugs and features can be posted here
>>>> Csound mailing list
>>>> Csound@listserv.heanet.ie
>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>> Send bugs reports to
>>>>       https://github.com/csound/csound/issues
>>>> Discussions of bugs and features can be posted here
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>        https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>        https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

That shouldn't happen, the array should grow. I'll have a look and fix it.

Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy
Maynooth University
Ireland

> On 7 Apr 2017, at 04:30, Guillermo Senna  wrote:
> 
> I tested the new specifier from outside Csound. Now I understand what
> you mean Victor. The good thing is that it forces you to choose a common
> size between sender and receiver in advance and that prevents you from
> getting "osc::OutOfBufferMemoryException" while sending exceedingly
> large vectors. The bad thing is the need to process the received array
> and look for a delimiter while sending variable-sized arrays like I'm
> doing. Or maybe I can just send the size before through "/kArrSize" or
> something like that.
> 
> Just for the record, with the "A" specifier you can do "kArr[] init 1"
> and the array will still grow and shrink dynamically according to
> dimensions/sizes received. That is very convenient. With the "D"
> specifier you get "Array index 2 out of range (0,0) for dimension 1".
> 
> I've to think now how to effectively process the received the array, but
> I think you saved me from a difficult-to-diagnose bug that I'd probably
> have encountered in the future because of the UDP protocol.
> 
> I'll test OSCsend2 now. Cheers.
> 
> 
>> On 06/04/17 18:33, Victor Lazzarini wrote:
>> Say you send 10 elements.
>> 
>> You can interpret this as
>> 
>> [1,2,3,4,5,6,7,8,9,10]
>> 
>> or
>> 
>> [1,2]
>> [3,4]
>> [5,6]
>> [7,8]
>> 
>> or
>> 
>> [1,2,3,4,5]
>> [6,7,8,9,10]
>> 
>> or
>> 
>> [1,2,3]
>> [4,5,6]
>> [7,8,9]
>> [10,0,0]
>> 
>> etc
>> 
>> Whatever you do, if there isn’t enough size, the array grows dynamically. In the last
>> example there was more than enough size, but we only copied  the 10 numbers
>> we got.
>> 
>> I have added this type to OSClisten  and OSCsend2. 
>> 
>> ========================
>> Prof. Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy,
>> Maynooth University,
>> Maynooth, Co Kildare, Ireland
>> Tel: 00 353 7086936
>> Fax: 00 353 1 7086952 
>> 
>>> On 6 Apr 2017, at 22:20, Guillermo Senna  wrote:
>>> 
>>> Oh, I see. And in the 2D version, if I send a single blob/array with:
>>> 
>>> 10 elements -> they all end up in dimension no. 1
>>> 
>>> 30 elements -> they'd go 16-14
>>> 
>>> 40 elements -> 16-24
>>> 
>>> Or is it going to be an error not to match the dimensions/sizes?
>>> 
>>>> On 06/04/17 18:10, Victor Lazzarini wrote:
>>>> No, I mean
>>>> 
>>>> kArr[][] init 2, 16
>>>> kk1  OSClisten gihandle, "/multiArr", "D", kArr
>>>> 
>>>> or
>>>> 
>>>> kArr[] init 32
>>>> kk1  OSClisten gihandle, "/multiArr", "D", kArr
>>>> 
>>>> both working, the choice is yours
>>>> 
>>>> 
>>>> ========================
>>>> Prof. Victor Lazzarini
>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>> Maynooth University,
>>>> Maynooth, Co Kildare, Ireland
>>>> Tel: 00 353 7086936
>>>> Fax: 00 353 1 7086952 
>>>> 
>>>>> On 6 Apr 2017, at 21:46, Guillermo Senna  wrote:
>>>>> 
>>>>> I'm not so sure I follow you with that last sentence. Do you mean
>>>>> something like this could be possible?
>>>>> 
>>>>> kArr[][] init 2, 16
>>>>> kk1  OSClisten gihandle, "/multiArr", "DD", kArr[0], kArr[1]
>>>>> 
>>>>> 
>>>>> 
>>>>>> On 06/04/17 17:36, Victor Lazzarini wrote:
>>>>>> yes, same thing from the user perspective. Except that you can define how many dimensions you want
>>>>>> to hold the data in.
>>>>>> ========================
>>>>>> Prof. Victor Lazzarini
>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>> Maynooth University,
>>>>>> Maynooth, Co Kildare, Ireland
>>>>>> Tel: 00 353 7086936
>>>>>> Fax: 00 353 1 7086952 
>>>>>> 
>>>>>>> On 6 Apr 2017, at 21:33, Guillermo Senna  wrote:
>>>>>>> 
>>>>>>> I like that. Non of those characters are really part of the OSC
>>>>>>> specification, so why not?
>>>>>>> 
>>>>>>> But with this approach you would still use a Csound array as xdata1 in
>>>>>>> OSClisten, right?
>>>>>>> 
>>>>>>>> On 06/04/17 17:16, Victor Lazzarini wrote:
>>>>>>>> We could put in a different type name for non-descript double-format data sequence (e.g. 2), for instance
>>>>>>>> call it “D”.
>>>>>>>> ========================
>>>>>>>> Prof. Victor Lazzarini
>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>> Maynooth University,
>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>> Tel: 00 353 7086936
>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>> 
>>>>>>>>> On 6 Apr 2017, at 21:04, Guillermo Senna  wrote:
>>>>>>>>> 
>>>>>>>>> I've not considered number 2 before. How about adding an opcode later
>>>>>>>>> for joining 2d arrays into a single multidimensional? Would it be to
>>>>>>>>> difficult/inefficient to do that considering that in the end it's all
>>>>>>>>> about pointers?
>>>>>>>>> 
>>>>>>>>> I don't want to change and break it for others already using the current
>>>>>>>>> structure.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> On 05/04/17 18:12, Victor Lazzarini wrote:
>>>>>>>>>> I see what you mean. It’s possible to change it, there are two options:
>>>>>>>>>> 
>>>>>>>>>> 1) encode everything with doubles
>>>>>>>>>> 2) leave dim and size. The size of the blob is always there before the
>>>>>>>>>> data, so we can just use that. It will be then up to the user to interpret
>>>>>>>>>> the data as a 1,2,3 ,… dimensional array. The data is always stored
>>>>>>>>>> as a flat vector (e.g. row-column for 2-d).
>>>>>>>>>> 
>>>>>>>>>> if people want it changed, I can do it.
>>>>>>>>>> ========================
>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>> Maynooth University,
>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>> 
>>>>>>>>>>> On 5 Apr 2017, at 18:24, Guillermo Senna  wrote:
>>>>>>>>>>> 
>>>>>>>>>>> My reasoning is that in the different programming languages you'd use a
>>>>>>>>>>> library/module for handling the OSC part and that would in turn have
>>>>>>>>>>> some abstraction for sending entire arrays as blobs. Now, Csound
>>>>>>>>>>> requests for two 32-bit ints and then the rest 64-bits doubles. Is that
>>>>>>>>>>> always possible to control in the higher-level languages?
>>>>>>>>>>> 
>>>>>>>>>>> Initially what I'd have thought is that I could build an array with all
>>>>>>>>>>> doubles and Csound would internally truncate the first two values and
>>>>>>>>>>> cast them into ints.
>>>>>>>>>>> 
>>>>>>>>>>> But if it's working for everyone right now nothing should be changed!
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> On 05/04/17 14:04, Victor Lazzarini wrote:
>>>>>>>>>>>> Well, Csound reads two ints, as far as I can see. So I would expect that you can just send two
>>>>>>>>>>>> separate ints and Csound would understand it (first the dimension, then the size). This is
>>>>>>>>>>>> what OSCsend2 (& OSCsend) does. Not quite sure what might be going on at your end.
>>>>>>>>>>>> ========================
>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>> 
>>>>>>>>>>>>> On 5 Apr 2017, at 17:44, Guillermo Senna  wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Well I'm doing it in C++ with oscpack and for me it works. Now, I don't
>>>>>>>>>>>>> know much about python for example, but if you are using a python module
>>>>>>>>>>>>> for handling the OSC part of your program, is it possible to construct
>>>>>>>>>>>>> the array to be sent as two ints and the rest as doubles?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I'm asking from complete ignorance, Victor. It just seemed odd to
>>>>>>>>>>>>> (instead of passing my entire vector in C++) have to do something like this:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> unsigned long ui = qvlist.size();
>>>>>>>>>>>>> ui <<= 32; ui |= 1;
>>>>>>>>>>>>> vec.push_back (*(double*)&ui);
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On 05/04/17 13:30, Victor Lazzarini wrote:
>>>>>>>>>>>>>> I have implemented the array, audio and function table as per OSCsend/OSClisten. As far as I can see from the code, the blob is as you
>>>>>>>>>>>>>> describe, all data being sent in the native endianess (little endian for i386/x86_64). It could be that the OSC lib is expecting the data
>>>>>>>>>>>>>> in big-endian ints, 4 bytes at a time. As far as I understand, the OSC should not impose any particular interpretation to the blob,
>>>>>>>>>>>>>> but just take it as a string of bytes.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On 5 Apr 2017, at 17:03, Guillermo Senna  wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I'll try it in a few moments. Are you going to replace OSClisten too? If
>>>>>>>>>>>>>>> you do, please beware that right now receiving an array in Csound
>>>>>>>>>>>>>>> expects the structure [dimensions(int); size(int); values(double)...]. I
>>>>>>>>>>>>>>> had to bitshift and cast two ints as a double in order to make that work
>>>>>>>>>>>>>>> from a third-party OSC library outside Csound. It didn't seem right and
>>>>>>>>>>>>>>> I don't think it's possible in every programming language.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Cheers.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On 05/04/17 08:30, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>> Following our conclusion that liblo seems to be overly heavy weight for OSC sending, I have
>>>>>>>>>>>>>>>> implemented an alternative version that uses UDP sockets directly. It is currently called
>>>>>>>>>>>>>>>> OSCsend2 and the interface is exactly the same to OSCsend. In our tests, it appears to
>>>>>>>>>>>>>>>> do the job, but have not tested it extensively.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> It has been suggested to remove OSCsend and replace it with OSCsend2, so I would
>>>>>>>>>>>>>>>> like to check if OSCsend users could test OSCsend2 and let us know if there are differences
>>>>>>>>>>>>>>>> and whether it works OK for you. We would also then like to know whether having
>>>>>>>>>>>>>>>> OSCsend2 alongside OSCsend is your preference, or whether we should just replace it.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>  https://github.com/csound/csound/issues
>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>  https://github.com/csound/csound/issues
>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>   https://github.com/csound/csound/issues
>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>> Csound mailing list
>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>   https://github.com/csound/csound/issues
>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>> Csound mailing list
>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>> Send bugs reports to
>>>>>>>>>>    https://github.com/csound/csound/issues
>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>> Csound mailing list
>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>> Send bugs reports to
>>>>>>>>>    https://github.com/csound/csound/issues
>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>> Csound mailing list
>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>> Send bugs reports to
>>>>>>>>     https://github.com/csound/csound/issues
>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>> Csound mailing list
>>>>>>> Csound@listserv.heanet.ie
>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>> Send bugs reports to
>>>>>>>     https://github.com/csound/csound/issues
>>>>>>> Discussions of bugs and features can be posted here
>>>>>> Csound mailing list
>>>>>> Csound@listserv.heanet.ie
>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>> Send bugs reports to
>>>>>>      https://github.com/csound/csound/issues
>>>>>> Discussions of bugs and features can be posted here
>>>>> Csound mailing list
>>>>> Csound@listserv.heanet.ie
>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>> Send bugs reports to
>>>>>      https://github.com/csound/csound/issues
>>>>> Discussions of bugs and features can be posted here
>>>> Csound mailing list
>>>> Csound@listserv.heanet.ie
>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>> Send bugs reports to
>>>>       https://github.com/csound/csound/issues
>>>> Discussions of bugs and features can be posted here
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>       https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>> 
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>        https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
> 
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

It should be fixed now. The array was growing but I forgot to update the sizes.
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 7 Apr 2017, at 06:16, Victor Lazzarini  wrote:
> 
> That shouldn't happen, the array should grow. I'll have a look and fix it.
> 
> Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy
> Maynooth University
> Ireland
> 
>> On 7 Apr 2017, at 04:30, Guillermo Senna  wrote:
>> 
>> I tested the new specifier from outside Csound. Now I understand what
>> you mean Victor. The good thing is that it forces you to choose a common
>> size between sender and receiver in advance and that prevents you from
>> getting "osc::OutOfBufferMemoryException" while sending exceedingly
>> large vectors. The bad thing is the need to process the received array
>> and look for a delimiter while sending variable-sized arrays like I'm
>> doing. Or maybe I can just send the size before through "/kArrSize" or
>> something like that.
>> 
>> Just for the record, with the "A" specifier you can do "kArr[] init 1"
>> and the array will still grow and shrink dynamically according to
>> dimensions/sizes received. That is very convenient. With the "D"
>> specifier you get "Array index 2 out of range (0,0) for dimension 1".
>> 
>> I've to think now how to effectively process the received the array, but
>> I think you saved me from a difficult-to-diagnose bug that I'd probably
>> have encountered in the future because of the UDP protocol.
>> 
>> I'll test OSCsend2 now. Cheers.
>> 
>> 
>>> On 06/04/17 18:33, Victor Lazzarini wrote:
>>> Say you send 10 elements.
>>> 
>>> You can interpret this as
>>> 
>>> [1,2,3,4,5,6,7,8,9,10]
>>> 
>>> or
>>> 
>>> [1,2]
>>> [3,4]
>>> [5,6]
>>> [7,8]
>>> 
>>> or
>>> 
>>> [1,2,3,4,5]
>>> [6,7,8,9,10]
>>> 
>>> or
>>> 
>>> [1,2,3]
>>> [4,5,6]
>>> [7,8,9]
>>> [10,0,0]
>>> 
>>> etc
>>> 
>>> Whatever you do, if there isn’t enough size, the array grows dynamically. In the last
>>> example there was more than enough size, but we only copied  the 10 numbers
>>> we got.
>>> 
>>> I have added this type to OSClisten  and OSCsend2. 
>>> 
>>> ========================
>>> Prof. Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy,
>>> Maynooth University,
>>> Maynooth, Co Kildare, Ireland
>>> Tel: 00 353 7086936
>>> Fax: 00 353 1 7086952 
>>> 
>>>> On 6 Apr 2017, at 22:20, Guillermo Senna  wrote:
>>>> 
>>>> Oh, I see. And in the 2D version, if I send a single blob/array with:
>>>> 
>>>> 10 elements -> they all end up in dimension no. 1
>>>> 
>>>> 30 elements -> they'd go 16-14
>>>> 
>>>> 40 elements -> 16-24
>>>> 
>>>> Or is it going to be an error not to match the dimensions/sizes?
>>>> 
>>>>> On 06/04/17 18:10, Victor Lazzarini wrote:
>>>>> No, I mean
>>>>> 
>>>>> kArr[][] init 2, 16
>>>>> kk1  OSClisten gihandle, "/multiArr", "D", kArr
>>>>> 
>>>>> or
>>>>> 
>>>>> kArr[] init 32
>>>>> kk1  OSClisten gihandle, "/multiArr", "D", kArr
>>>>> 
>>>>> both working, the choice is yours
>>>>> 
>>>>> 
>>>>> ========================
>>>>> Prof. Victor Lazzarini
>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>> Maynooth University,
>>>>> Maynooth, Co Kildare, Ireland
>>>>> Tel: 00 353 7086936
>>>>> Fax: 00 353 1 7086952 
>>>>> 
>>>>>> On 6 Apr 2017, at 21:46, Guillermo Senna  wrote:
>>>>>> 
>>>>>> I'm not so sure I follow you with that last sentence. Do you mean
>>>>>> something like this could be possible?
>>>>>> 
>>>>>> kArr[][] init 2, 16
>>>>>> kk1  OSClisten gihandle, "/multiArr", "DD", kArr[0], kArr[1]
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On 06/04/17 17:36, Victor Lazzarini wrote:
>>>>>>> yes, same thing from the user perspective. Except that you can define how many dimensions you want
>>>>>>> to hold the data in.
>>>>>>> ========================
>>>>>>> Prof. Victor Lazzarini
>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>> Maynooth University,
>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>> Tel: 00 353 7086936
>>>>>>> Fax: 00 353 1 7086952 
>>>>>>> 
>>>>>>>> On 6 Apr 2017, at 21:33, Guillermo Senna  wrote:
>>>>>>>> 
>>>>>>>> I like that. Non of those characters are really part of the OSC
>>>>>>>> specification, so why not?
>>>>>>>> 
>>>>>>>> But with this approach you would still use a Csound array as xdata1 in
>>>>>>>> OSClisten, right?
>>>>>>>> 
>>>>>>>>> On 06/04/17 17:16, Victor Lazzarini wrote:
>>>>>>>>> We could put in a different type name for non-descript double-format data sequence (e.g. 2), for instance
>>>>>>>>> call it “D”.
>>>>>>>>> ========================
>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>> Maynooth University,
>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>> 
>>>>>>>>>> On 6 Apr 2017, at 21:04, Guillermo Senna  wrote:
>>>>>>>>>> 
>>>>>>>>>> I've not considered number 2 before. How about adding an opcode later
>>>>>>>>>> for joining 2d arrays into a single multidimensional? Would it be to
>>>>>>>>>> difficult/inefficient to do that considering that in the end it's all
>>>>>>>>>> about pointers?
>>>>>>>>>> 
>>>>>>>>>> I don't want to change and break it for others already using the current
>>>>>>>>>> structure.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> On 05/04/17 18:12, Victor Lazzarini wrote:
>>>>>>>>>>> I see what you mean. It’s possible to change it, there are two options:
>>>>>>>>>>> 
>>>>>>>>>>> 1) encode everything with doubles
>>>>>>>>>>> 2) leave dim and size. The size of the blob is always there before the
>>>>>>>>>>> data, so we can just use that. It will be then up to the user to interpret
>>>>>>>>>>> the data as a 1,2,3 ,… dimensional array. The data is always stored
>>>>>>>>>>> as a flat vector (e.g. row-column for 2-d).
>>>>>>>>>>> 
>>>>>>>>>>> if people want it changed, I can do it.
>>>>>>>>>>> ========================
>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>> Maynooth University,
>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>> 
>>>>>>>>>>>> On 5 Apr 2017, at 18:24, Guillermo Senna  wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> My reasoning is that in the different programming languages you'd use a
>>>>>>>>>>>> library/module for handling the OSC part and that would in turn have
>>>>>>>>>>>> some abstraction for sending entire arrays as blobs. Now, Csound
>>>>>>>>>>>> requests for two 32-bit ints and then the rest 64-bits doubles. Is that
>>>>>>>>>>>> always possible to control in the higher-level languages?
>>>>>>>>>>>> 
>>>>>>>>>>>> Initially what I'd have thought is that I could build an array with all
>>>>>>>>>>>> doubles and Csound would internally truncate the first two values and
>>>>>>>>>>>> cast them into ints.
>>>>>>>>>>>> 
>>>>>>>>>>>> But if it's working for everyone right now nothing should be changed!
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>> On 05/04/17 14:04, Victor Lazzarini wrote:
>>>>>>>>>>>>> Well, Csound reads two ints, as far as I can see. So I would expect that you can just send two
>>>>>>>>>>>>> separate ints and Csound would understand it (first the dimension, then the size). This is
>>>>>>>>>>>>> what OSCsend2 (& OSCsend) does. Not quite sure what might be going on at your end.
>>>>>>>>>>>>> ========================
>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On 5 Apr 2017, at 17:44, Guillermo Senna  wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Well I'm doing it in C++ with oscpack and for me it works. Now, I don't
>>>>>>>>>>>>>> know much about python for example, but if you are using a python module
>>>>>>>>>>>>>> for handling the OSC part of your program, is it possible to construct
>>>>>>>>>>>>>> the array to be sent as two ints and the rest as doubles?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I'm asking from complete ignorance, Victor. It just seemed odd to
>>>>>>>>>>>>>> (instead of passing my entire vector in C++) have to do something like this:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> unsigned long ui = qvlist.size();
>>>>>>>>>>>>>> ui <<= 32; ui |= 1;
>>>>>>>>>>>>>> vec.push_back (*(double*)&ui);
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On 05/04/17 13:30, Victor Lazzarini wrote:
>>>>>>>>>>>>>>> I have implemented the array, audio and function table as per OSCsend/OSClisten. As far as I can see from the code, the blob is as you
>>>>>>>>>>>>>>> describe, all data being sent in the native endianess (little endian for i386/x86_64). It could be that the OSC lib is expecting the data
>>>>>>>>>>>>>>> in big-endian ints, 4 bytes at a time. As far as I understand, the OSC should not impose any particular interpretation to the blob,
>>>>>>>>>>>>>>> but just take it as a string of bytes.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On 5 Apr 2017, at 17:03, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> I'll try it in a few moments. Are you going to replace OSClisten too? If
>>>>>>>>>>>>>>>> you do, please beware that right now receiving an array in Csound
>>>>>>>>>>>>>>>> expects the structure [dimensions(int); size(int); values(double)...]. I
>>>>>>>>>>>>>>>> had to bitshift and cast two ints as a double in order to make that work
>>>>>>>>>>>>>>>> from a third-party OSC library outside Csound. It didn't seem right and
>>>>>>>>>>>>>>>> I don't think it's possible in every programming language.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Cheers.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On 05/04/17 08:30, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>> Following our conclusion that liblo seems to be overly heavy weight for OSC sending, I have
>>>>>>>>>>>>>>>>> implemented an alternative version that uses UDP sockets directly. It is currently called
>>>>>>>>>>>>>>>>> OSCsend2 and the interface is exactly the same to OSCsend. In our tests, it appears to
>>>>>>>>>>>>>>>>> do the job, but have not tested it extensively.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> It has been suggested to remove OSCsend and replace it with OSCsend2, so I would
>>>>>>>>>>>>>>>>> like to check if OSCsend users could test OSCsend2 and let us know if there are differences
>>>>>>>>>>>>>>>>> and whether it works OK for you. We would also then like to know whether having
>>>>>>>>>>>>>>>>> OSCsend2 alongside OSCsend is your preference, or whether we should just replace it.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>  https://github.com/csound/csound/issues
>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>  https://github.com/csound/csound/issues
>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>> Csound mailing list
>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>   https://github.com/csound/csound/issues
>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>> Csound mailing list
>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>> Send bugs reports to
>>>>>>>>>>   https://github.com/csound/csound/issues
>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>> Csound mailing list
>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>> Send bugs reports to
>>>>>>>>>    https://github.com/csound/csound/issues
>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>> Csound mailing list
>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>> Send bugs reports to
>>>>>>>>    https://github.com/csound/csound/issues
>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>> Csound mailing list
>>>>>>> Csound@listserv.heanet.ie
>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>> Send bugs reports to
>>>>>>>     https://github.com/csound/csound/issues
>>>>>>> Discussions of bugs and features can be posted here
>>>>>> Csound mailing list
>>>>>> Csound@listserv.heanet.ie
>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>> Send bugs reports to
>>>>>>     https://github.com/csound/csound/issues
>>>>>> Discussions of bugs and features can be posted here
>>>>> Csound mailing list
>>>>> Csound@listserv.heanet.ie
>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>> Send bugs reports to
>>>>>      https://github.com/csound/csound/issues
>>>>> Discussions of bugs and features can be posted here
>>>> Csound mailing list
>>>> Csound@listserv.heanet.ie
>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>> Send bugs reports to
>>>>      https://github.com/csound/csound/issues
>>>> Discussions of bugs and features can be posted here
>>> 
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>       https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>> 
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>       https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
> 
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here


Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Could it be that you are doing (dimensions+sizes) instead of
(dimensions*sizes) somewhere?

I'm sending:

giArr[][] init 2, 4
giArr[0][0] = 0
giArr[0][1] = 1
giArr[0][2] = 2
giArr[0][3] = 3

giArr[1][0] = 10
giArr[1][1] = 11
giArr[1][2] = 12
giArr[1][3] = 13

And I'm receiving:

0.00000
1.00000
2.00000
3.00000
10.00000
11.00000
0.00000
0.00000

Also, by reading the manual I get the impression that this should give
me the total size of a 2D array:

lenarray:i(kArr, 0) * lenarray:i(kArr).

But it says 4. And if I instead do:

lenarray:i(kArr, 1) + lenarray:i(kArr, 2)

It says 6.


On 07/04/17 02:39, Victor Lazzarini wrote:
> It should be fixed now. The array was growing but I forgot to update the sizes.
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952 
>
>> On 7 Apr 2017, at 06:16, Victor Lazzarini  wrote:
>>
>> That shouldn't happen, the array should grow. I'll have a look and fix it.
>>
>> Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy
>> Maynooth University
>> Ireland
>>
>>> On 7 Apr 2017, at 04:30, Guillermo Senna  wrote:
>>>
>>> I tested the new specifier from outside Csound. Now I understand what
>>> you mean Victor. The good thing is that it forces you to choose a common
>>> size between sender and receiver in advance and that prevents you from
>>> getting "osc::OutOfBufferMemoryException" while sending exceedingly
>>> large vectors. The bad thing is the need to process the received array
>>> and look for a delimiter while sending variable-sized arrays like I'm
>>> doing. Or maybe I can just send the size before through "/kArrSize" or
>>> something like that.
>>>
>>> Just for the record, with the "A" specifier you can do "kArr[] init 1"
>>> and the array will still grow and shrink dynamically according to
>>> dimensions/sizes received. That is very convenient. With the "D"
>>> specifier you get "Array index 2 out of range (0,0) for dimension 1".
>>>
>>> I've to think now how to effectively process the received the array, but
>>> I think you saved me from a difficult-to-diagnose bug that I'd probably
>>> have encountered in the future because of the UDP protocol.
>>>
>>> I'll test OSCsend2 now. Cheers.
>>>
>>>
>>>> On 06/04/17 18:33, Victor Lazzarini wrote:
>>>> Say you send 10 elements.
>>>>
>>>> You can interpret this as
>>>>
>>>> [1,2,3,4,5,6,7,8,9,10]
>>>>
>>>> or
>>>>
>>>> [1,2]
>>>> [3,4]
>>>> [5,6]
>>>> [7,8]
>>>>
>>>> or
>>>>
>>>> [1,2,3,4,5]
>>>> [6,7,8,9,10]
>>>>
>>>> or
>>>>
>>>> [1,2,3]
>>>> [4,5,6]
>>>> [7,8,9]
>>>> [10,0,0]
>>>>
>>>> etc
>>>>
>>>> Whatever you do, if there isn’t enough size, the array grows dynamically. In the last
>>>> example there was more than enough size, but we only copied  the 10 numbers
>>>> we got.
>>>>
>>>> I have added this type to OSClisten  and OSCsend2. 
>>>>
>>>> ========================
>>>> Prof. Victor Lazzarini
>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>> Maynooth University,
>>>> Maynooth, Co Kildare, Ireland
>>>> Tel: 00 353 7086936
>>>> Fax: 00 353 1 7086952 
>>>>
>>>>> On 6 Apr 2017, at 22:20, Guillermo Senna  wrote:
>>>>>
>>>>> Oh, I see. And in the 2D version, if I send a single blob/array with:
>>>>>
>>>>> 10 elements -> they all end up in dimension no. 1
>>>>>
>>>>> 30 elements -> they'd go 16-14
>>>>>
>>>>> 40 elements -> 16-24
>>>>>
>>>>> Or is it going to be an error not to match the dimensions/sizes?
>>>>>
>>>>>> On 06/04/17 18:10, Victor Lazzarini wrote:
>>>>>> No, I mean
>>>>>>
>>>>>> kArr[][] init 2, 16
>>>>>> kk1  OSClisten gihandle, "/multiArr", "D", kArr
>>>>>>
>>>>>> or
>>>>>>
>>>>>> kArr[] init 32
>>>>>> kk1  OSClisten gihandle, "/multiArr", "D", kArr
>>>>>>
>>>>>> both working, the choice is yours
>>>>>>
>>>>>>
>>>>>> ========================
>>>>>> Prof. Victor Lazzarini
>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>> Maynooth University,
>>>>>> Maynooth, Co Kildare, Ireland
>>>>>> Tel: 00 353 7086936
>>>>>> Fax: 00 353 1 7086952 
>>>>>>
>>>>>>> On 6 Apr 2017, at 21:46, Guillermo Senna  wrote:
>>>>>>>
>>>>>>> I'm not so sure I follow you with that last sentence. Do you mean
>>>>>>> something like this could be possible?
>>>>>>>
>>>>>>> kArr[][] init 2, 16
>>>>>>> kk1  OSClisten gihandle, "/multiArr", "DD", kArr[0], kArr[1]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On 06/04/17 17:36, Victor Lazzarini wrote:
>>>>>>>> yes, same thing from the user perspective. Except that you can define how many dimensions you want
>>>>>>>> to hold the data in.
>>>>>>>> ========================
>>>>>>>> Prof. Victor Lazzarini
>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>> Maynooth University,
>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>> Tel: 00 353 7086936
>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>
>>>>>>>>> On 6 Apr 2017, at 21:33, Guillermo Senna  wrote:
>>>>>>>>>
>>>>>>>>> I like that. Non of those characters are really part of the OSC
>>>>>>>>> specification, so why not?
>>>>>>>>>
>>>>>>>>> But with this approach you would still use a Csound array as xdata1 in
>>>>>>>>> OSClisten, right?
>>>>>>>>>
>>>>>>>>>> On 06/04/17 17:16, Victor Lazzarini wrote:
>>>>>>>>>> We could put in a different type name for non-descript double-format data sequence (e.g. 2), for instance
>>>>>>>>>> call it “D”.
>>>>>>>>>> ========================
>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>> Maynooth University,
>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>
>>>>>>>>>>> On 6 Apr 2017, at 21:04, Guillermo Senna  wrote:
>>>>>>>>>>>
>>>>>>>>>>> I've not considered number 2 before. How about adding an opcode later
>>>>>>>>>>> for joining 2d arrays into a single multidimensional? Would it be to
>>>>>>>>>>> difficult/inefficient to do that considering that in the end it's all
>>>>>>>>>>> about pointers?
>>>>>>>>>>>
>>>>>>>>>>> I don't want to change and break it for others already using the current
>>>>>>>>>>> structure.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> On 05/04/17 18:12, Victor Lazzarini wrote:
>>>>>>>>>>>> I see what you mean. It’s possible to change it, there are two options:
>>>>>>>>>>>>
>>>>>>>>>>>> 1) encode everything with doubles
>>>>>>>>>>>> 2) leave dim and size. The size of the blob is always there before the
>>>>>>>>>>>> data, so we can just use that. It will be then up to the user to interpret
>>>>>>>>>>>> the data as a 1,2,3 ,… dimensional array. The data is always stored
>>>>>>>>>>>> as a flat vector (e.g. row-column for 2-d).
>>>>>>>>>>>>
>>>>>>>>>>>> if people want it changed, I can do it.
>>>>>>>>>>>> ========================
>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>
>>>>>>>>>>>>> On 5 Apr 2017, at 18:24, Guillermo Senna  wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> My reasoning is that in the different programming languages you'd use a
>>>>>>>>>>>>> library/module for handling the OSC part and that would in turn have
>>>>>>>>>>>>> some abstraction for sending entire arrays as blobs. Now, Csound
>>>>>>>>>>>>> requests for two 32-bit ints and then the rest 64-bits doubles. Is that
>>>>>>>>>>>>> always possible to control in the higher-level languages?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Initially what I'd have thought is that I could build an array with all
>>>>>>>>>>>>> doubles and Csound would internally truncate the first two values and
>>>>>>>>>>>>> cast them into ints.
>>>>>>>>>>>>>
>>>>>>>>>>>>> But if it's working for everyone right now nothing should be changed!
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 05/04/17 14:04, Victor Lazzarini wrote:
>>>>>>>>>>>>>> Well, Csound reads two ints, as far as I can see. So I would expect that you can just send two
>>>>>>>>>>>>>> separate ints and Csound would understand it (first the dimension, then the size). This is
>>>>>>>>>>>>>> what OSCsend2 (& OSCsend) does. Not quite sure what might be going on at your end.
>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 5 Apr 2017, at 17:44, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Well I'm doing it in C++ with oscpack and for me it works. Now, I don't
>>>>>>>>>>>>>>> know much about python for example, but if you are using a python module
>>>>>>>>>>>>>>> for handling the OSC part of your program, is it possible to construct
>>>>>>>>>>>>>>> the array to be sent as two ints and the rest as doubles?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm asking from complete ignorance, Victor. It just seemed odd to
>>>>>>>>>>>>>>> (instead of passing my entire vector in C++) have to do something like this:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> unsigned long ui = qvlist.size();
>>>>>>>>>>>>>>> ui <<= 32; ui |= 1;
>>>>>>>>>>>>>>> vec.push_back (*(double*)&ui);
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 05/04/17 13:30, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>> I have implemented the array, audio and function table as per OSCsend/OSClisten. As far as I can see from the code, the blob is as you
>>>>>>>>>>>>>>>> describe, all data being sent in the native endianess (little endian for i386/x86_64). It could be that the OSC lib is expecting the data
>>>>>>>>>>>>>>>> in big-endian ints, 4 bytes at a time. As far as I understand, the OSC should not impose any particular interpretation to the blob,
>>>>>>>>>>>>>>>> but just take it as a string of bytes.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 5 Apr 2017, at 17:03, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I'll try it in a few moments. Are you going to replace OSClisten too? If
>>>>>>>>>>>>>>>>> you do, please beware that right now receiving an array in Csound
>>>>>>>>>>>>>>>>> expects the structure [dimensions(int); size(int); values(double)...]. I
>>>>>>>>>>>>>>>>> had to bitshift and cast two ints as a double in order to make that work
>>>>>>>>>>>>>>>>> from a third-party OSC library outside Csound. It didn't seem right and
>>>>>>>>>>>>>>>>> I don't think it's possible in every programming language.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Cheers.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 05/04/17 08:30, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>> Following our conclusion that liblo seems to be overly heavy weight for OSC sending, I have
>>>>>>>>>>>>>>>>>> implemented an alternative version that uses UDP sockets directly. It is currently called
>>>>>>>>>>>>>>>>>> OSCsend2 and the interface is exactly the same to OSCsend. In our tests, it appears to
>>>>>>>>>>>>>>>>>> do the job, but have not tested it extensively.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It has been suggested to remove OSCsend and replace it with OSCsend2, so I would
>>>>>>>>>>>>>>>>>> like to check if OSCsend users could test OSCsend2 and let us know if there are differences
>>>>>>>>>>>>>>>>>> and whether it works OK for you. We would also then like to know whether having
>>>>>>>>>>>>>>>>>> OSCsend2 alongside OSCsend is your preference, or whether we should just replace it.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>  https://github.com/csound/csound/issues
>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>  https://github.com/csound/csound/issues
>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>   https://github.com/csound/csound/issues
>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>> Csound mailing list
>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>   https://github.com/csound/csound/issues
>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>> Csound mailing list
>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>> Send bugs reports to
>>>>>>>>>>    https://github.com/csound/csound/issues
>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>> Csound mailing list
>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>> Send bugs reports to
>>>>>>>>>    https://github.com/csound/csound/issues
>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>> Csound mailing list
>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>> Send bugs reports to
>>>>>>>>     https://github.com/csound/csound/issues
>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>> Csound mailing list
>>>>>>> Csound@listserv.heanet.ie
>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>> Send bugs reports to
>>>>>>>     https://github.com/csound/csound/issues
>>>>>>> Discussions of bugs and features can be posted here
>>>>>> Csound mailing list
>>>>>> Csound@listserv.heanet.ie
>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>> Send bugs reports to
>>>>>>      https://github.com/csound/csound/issues
>>>>>> Discussions of bugs and features can be posted here
>>>>> Csound mailing list
>>>>> Csound@listserv.heanet.ie
>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>> Send bugs reports to
>>>>>      https://github.com/csound/csound/issues
>>>>> Discussions of bugs and features can be posted here
>>>> Csound mailing list
>>>> Csound@listserv.heanet.ie
>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>> Send bugs reports to
>>>>       https://github.com/csound/csound/issues
>>>> Discussions of bugs and features can be posted here
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>       https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>        https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

If I send a unidimensional array (from inside or outside Csound) it does
grow organically!


On 07/04/17 02:39, Victor Lazzarini wrote:
> It should be fixed now. The array was growing but I forgot to update the sizes.
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952 
>
>> On 7 Apr 2017, at 06:16, Victor Lazzarini  wrote:
>>
>> That shouldn't happen, the array should grow. I'll have a look and fix it.
>>
>> Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy
>> Maynooth University
>> Ireland
>>
>>> On 7 Apr 2017, at 04:30, Guillermo Senna  wrote:
>>>
>>> I tested the new specifier from outside Csound. Now I understand what
>>> you mean Victor. The good thing is that it forces you to choose a common
>>> size between sender and receiver in advance and that prevents you from
>>> getting "osc::OutOfBufferMemoryException" while sending exceedingly
>>> large vectors. The bad thing is the need to process the received array
>>> and look for a delimiter while sending variable-sized arrays like I'm
>>> doing. Or maybe I can just send the size before through "/kArrSize" or
>>> something like that.
>>>
>>> Just for the record, with the "A" specifier you can do "kArr[] init 1"
>>> and the array will still grow and shrink dynamically according to
>>> dimensions/sizes received. That is very convenient. With the "D"
>>> specifier you get "Array index 2 out of range (0,0) for dimension 1".
>>>
>>> I've to think now how to effectively process the received the array, but
>>> I think you saved me from a difficult-to-diagnose bug that I'd probably
>>> have encountered in the future because of the UDP protocol.
>>>
>>> I'll test OSCsend2 now. Cheers.
>>>
>>>
>>>> On 06/04/17 18:33, Victor Lazzarini wrote:
>>>> Say you send 10 elements.
>>>>
>>>> You can interpret this as
>>>>
>>>> [1,2,3,4,5,6,7,8,9,10]
>>>>
>>>> or
>>>>
>>>> [1,2]
>>>> [3,4]
>>>> [5,6]
>>>> [7,8]
>>>>
>>>> or
>>>>
>>>> [1,2,3,4,5]
>>>> [6,7,8,9,10]
>>>>
>>>> or
>>>>
>>>> [1,2,3]
>>>> [4,5,6]
>>>> [7,8,9]
>>>> [10,0,0]
>>>>
>>>> etc
>>>>
>>>> Whatever you do, if there isn’t enough size, the array grows dynamically. In the last
>>>> example there was more than enough size, but we only copied  the 10 numbers
>>>> we got.
>>>>
>>>> I have added this type to OSClisten  and OSCsend2. 
>>>>
>>>> ========================
>>>> Prof. Victor Lazzarini
>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>> Maynooth University,
>>>> Maynooth, Co Kildare, Ireland
>>>> Tel: 00 353 7086936
>>>> Fax: 00 353 1 7086952 
>>>>
>>>>> On 6 Apr 2017, at 22:20, Guillermo Senna  wrote:
>>>>>
>>>>> Oh, I see. And in the 2D version, if I send a single blob/array with:
>>>>>
>>>>> 10 elements -> they all end up in dimension no. 1
>>>>>
>>>>> 30 elements -> they'd go 16-14
>>>>>
>>>>> 40 elements -> 16-24
>>>>>
>>>>> Or is it going to be an error not to match the dimensions/sizes?
>>>>>
>>>>>> On 06/04/17 18:10, Victor Lazzarini wrote:
>>>>>> No, I mean
>>>>>>
>>>>>> kArr[][] init 2, 16
>>>>>> kk1  OSClisten gihandle, "/multiArr", "D", kArr
>>>>>>
>>>>>> or
>>>>>>
>>>>>> kArr[] init 32
>>>>>> kk1  OSClisten gihandle, "/multiArr", "D", kArr
>>>>>>
>>>>>> both working, the choice is yours
>>>>>>
>>>>>>
>>>>>> ========================
>>>>>> Prof. Victor Lazzarini
>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>> Maynooth University,
>>>>>> Maynooth, Co Kildare, Ireland
>>>>>> Tel: 00 353 7086936
>>>>>> Fax: 00 353 1 7086952 
>>>>>>
>>>>>>> On 6 Apr 2017, at 21:46, Guillermo Senna  wrote:
>>>>>>>
>>>>>>> I'm not so sure I follow you with that last sentence. Do you mean
>>>>>>> something like this could be possible?
>>>>>>>
>>>>>>> kArr[][] init 2, 16
>>>>>>> kk1  OSClisten gihandle, "/multiArr", "DD", kArr[0], kArr[1]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On 06/04/17 17:36, Victor Lazzarini wrote:
>>>>>>>> yes, same thing from the user perspective. Except that you can define how many dimensions you want
>>>>>>>> to hold the data in.
>>>>>>>> ========================
>>>>>>>> Prof. Victor Lazzarini
>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>> Maynooth University,
>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>> Tel: 00 353 7086936
>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>
>>>>>>>>> On 6 Apr 2017, at 21:33, Guillermo Senna  wrote:
>>>>>>>>>
>>>>>>>>> I like that. Non of those characters are really part of the OSC
>>>>>>>>> specification, so why not?
>>>>>>>>>
>>>>>>>>> But with this approach you would still use a Csound array as xdata1 in
>>>>>>>>> OSClisten, right?
>>>>>>>>>
>>>>>>>>>> On 06/04/17 17:16, Victor Lazzarini wrote:
>>>>>>>>>> We could put in a different type name for non-descript double-format data sequence (e.g. 2), for instance
>>>>>>>>>> call it “D”.
>>>>>>>>>> ========================
>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>> Maynooth University,
>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>
>>>>>>>>>>> On 6 Apr 2017, at 21:04, Guillermo Senna  wrote:
>>>>>>>>>>>
>>>>>>>>>>> I've not considered number 2 before. How about adding an opcode later
>>>>>>>>>>> for joining 2d arrays into a single multidimensional? Would it be to
>>>>>>>>>>> difficult/inefficient to do that considering that in the end it's all
>>>>>>>>>>> about pointers?
>>>>>>>>>>>
>>>>>>>>>>> I don't want to change and break it for others already using the current
>>>>>>>>>>> structure.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> On 05/04/17 18:12, Victor Lazzarini wrote:
>>>>>>>>>>>> I see what you mean. It’s possible to change it, there are two options:
>>>>>>>>>>>>
>>>>>>>>>>>> 1) encode everything with doubles
>>>>>>>>>>>> 2) leave dim and size. The size of the blob is always there before the
>>>>>>>>>>>> data, so we can just use that. It will be then up to the user to interpret
>>>>>>>>>>>> the data as a 1,2,3 ,… dimensional array. The data is always stored
>>>>>>>>>>>> as a flat vector (e.g. row-column for 2-d).
>>>>>>>>>>>>
>>>>>>>>>>>> if people want it changed, I can do it.
>>>>>>>>>>>> ========================
>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>
>>>>>>>>>>>>> On 5 Apr 2017, at 18:24, Guillermo Senna  wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> My reasoning is that in the different programming languages you'd use a
>>>>>>>>>>>>> library/module for handling the OSC part and that would in turn have
>>>>>>>>>>>>> some abstraction for sending entire arrays as blobs. Now, Csound
>>>>>>>>>>>>> requests for two 32-bit ints and then the rest 64-bits doubles. Is that
>>>>>>>>>>>>> always possible to control in the higher-level languages?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Initially what I'd have thought is that I could build an array with all
>>>>>>>>>>>>> doubles and Csound would internally truncate the first two values and
>>>>>>>>>>>>> cast them into ints.
>>>>>>>>>>>>>
>>>>>>>>>>>>> But if it's working for everyone right now nothing should be changed!
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 05/04/17 14:04, Victor Lazzarini wrote:
>>>>>>>>>>>>>> Well, Csound reads two ints, as far as I can see. So I would expect that you can just send two
>>>>>>>>>>>>>> separate ints and Csound would understand it (first the dimension, then the size). This is
>>>>>>>>>>>>>> what OSCsend2 (& OSCsend) does. Not quite sure what might be going on at your end.
>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 5 Apr 2017, at 17:44, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Well I'm doing it in C++ with oscpack and for me it works. Now, I don't
>>>>>>>>>>>>>>> know much about python for example, but if you are using a python module
>>>>>>>>>>>>>>> for handling the OSC part of your program, is it possible to construct
>>>>>>>>>>>>>>> the array to be sent as two ints and the rest as doubles?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm asking from complete ignorance, Victor. It just seemed odd to
>>>>>>>>>>>>>>> (instead of passing my entire vector in C++) have to do something like this:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> unsigned long ui = qvlist.size();
>>>>>>>>>>>>>>> ui <<= 32; ui |= 1;
>>>>>>>>>>>>>>> vec.push_back (*(double*)&ui);
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 05/04/17 13:30, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>> I have implemented the array, audio and function table as per OSCsend/OSClisten. As far as I can see from the code, the blob is as you
>>>>>>>>>>>>>>>> describe, all data being sent in the native endianess (little endian for i386/x86_64). It could be that the OSC lib is expecting the data
>>>>>>>>>>>>>>>> in big-endian ints, 4 bytes at a time. As far as I understand, the OSC should not impose any particular interpretation to the blob,
>>>>>>>>>>>>>>>> but just take it as a string of bytes.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 5 Apr 2017, at 17:03, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I'll try it in a few moments. Are you going to replace OSClisten too? If
>>>>>>>>>>>>>>>>> you do, please beware that right now receiving an array in Csound
>>>>>>>>>>>>>>>>> expects the structure [dimensions(int); size(int); values(double)...]. I
>>>>>>>>>>>>>>>>> had to bitshift and cast two ints as a double in order to make that work
>>>>>>>>>>>>>>>>> from a third-party OSC library outside Csound. It didn't seem right and
>>>>>>>>>>>>>>>>> I don't think it's possible in every programming language.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Cheers.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 05/04/17 08:30, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>> Following our conclusion that liblo seems to be overly heavy weight for OSC sending, I have
>>>>>>>>>>>>>>>>>> implemented an alternative version that uses UDP sockets directly. It is currently called
>>>>>>>>>>>>>>>>>> OSCsend2 and the interface is exactly the same to OSCsend. In our tests, it appears to
>>>>>>>>>>>>>>>>>> do the job, but have not tested it extensively.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It has been suggested to remove OSCsend and replace it with OSCsend2, so I would
>>>>>>>>>>>>>>>>>> like to check if OSCsend users could test OSCsend2 and let us know if there are differences
>>>>>>>>>>>>>>>>>> and whether it works OK for you. We would also then like to know whether having
>>>>>>>>>>>>>>>>>> OSCsend2 alongside OSCsend is your preference, or whether we should just replace it.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>  https://github.com/csound/csound/issues
>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>  https://github.com/csound/csound/issues
>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>   https://github.com/csound/csound/issues
>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>> Csound mailing list
>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>   https://github.com/csound/csound/issues
>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>> Csound mailing list
>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>> Send bugs reports to
>>>>>>>>>>    https://github.com/csound/csound/issues
>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>> Csound mailing list
>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>> Send bugs reports to
>>>>>>>>>    https://github.com/csound/csound/issues
>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>> Csound mailing list
>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>> Send bugs reports to
>>>>>>>>     https://github.com/csound/csound/issues
>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>> Csound mailing list
>>>>>>> Csound@listserv.heanet.ie
>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>> Send bugs reports to
>>>>>>>     https://github.com/csound/csound/issues
>>>>>>> Discussions of bugs and features can be posted here
>>>>>> Csound mailing list
>>>>>> Csound@listserv.heanet.ie
>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>> Send bugs reports to
>>>>>>      https://github.com/csound/csound/issues
>>>>>> Discussions of bugs and features can be posted here
>>>>> Csound mailing list
>>>>> Csound@listserv.heanet.ie
>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>> Send bugs reports to
>>>>>      https://github.com/csound/csound/issues
>>>>> Discussions of bugs and features can be posted here
>>>> Csound mailing list
>>>> Csound@listserv.heanet.ie
>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>> Send bugs reports to
>>>>       https://github.com/csound/csound/issues
>>>> Discussions of bugs and features can be posted here
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>       https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>        https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

yes, I think I am mixing up dimension sizes, I will look. In any case, I will only be able to make one of the dimensions grow (as I can't guess how the matrix/cube/etc grows), whilst keeping the others fixed.

Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy
Maynooth University
Ireland

> On 7 Apr 2017, at 07:40, Guillermo Senna  wrote:
> 
> If I send a unidimensional array (from inside or outside Csound) it does
> grow organically!
> 
> 
>> On 07/04/17 02:39, Victor Lazzarini wrote:
>> It should be fixed now. The array was growing but I forgot to update the sizes.
>> ========================
>> Prof. Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy,
>> Maynooth University,
>> Maynooth, Co Kildare, Ireland
>> Tel: 00 353 7086936
>> Fax: 00 353 1 7086952 
>> 
>>> On 7 Apr 2017, at 06:16, Victor Lazzarini  wrote:
>>> 
>>> That shouldn't happen, the array should grow. I'll have a look and fix it.
>>> 
>>> Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy
>>> Maynooth University
>>> Ireland
>>> 
>>>> On 7 Apr 2017, at 04:30, Guillermo Senna  wrote:
>>>> 
>>>> I tested the new specifier from outside Csound. Now I understand what
>>>> you mean Victor. The good thing is that it forces you to choose a common
>>>> size between sender and receiver in advance and that prevents you from
>>>> getting "osc::OutOfBufferMemoryException" while sending exceedingly
>>>> large vectors. The bad thing is the need to process the received array
>>>> and look for a delimiter while sending variable-sized arrays like I'm
>>>> doing. Or maybe I can just send the size before through "/kArrSize" or
>>>> something like that.
>>>> 
>>>> Just for the record, with the "A" specifier you can do "kArr[] init 1"
>>>> and the array will still grow and shrink dynamically according to
>>>> dimensions/sizes received. That is very convenient. With the "D"
>>>> specifier you get "Array index 2 out of range (0,0) for dimension 1".
>>>> 
>>>> I've to think now how to effectively process the received the array, but
>>>> I think you saved me from a difficult-to-diagnose bug that I'd probably
>>>> have encountered in the future because of the UDP protocol.
>>>> 
>>>> I'll test OSCsend2 now. Cheers.
>>>> 
>>>> 
>>>>> On 06/04/17 18:33, Victor Lazzarini wrote:
>>>>> Say you send 10 elements.
>>>>> 
>>>>> You can interpret this as
>>>>> 
>>>>> [1,2,3,4,5,6,7,8,9,10]
>>>>> 
>>>>> or
>>>>> 
>>>>> [1,2]
>>>>> [3,4]
>>>>> [5,6]
>>>>> [7,8]
>>>>> 
>>>>> or
>>>>> 
>>>>> [1,2,3,4,5]
>>>>> [6,7,8,9,10]
>>>>> 
>>>>> or
>>>>> 
>>>>> [1,2,3]
>>>>> [4,5,6]
>>>>> [7,8,9]
>>>>> [10,0,0]
>>>>> 
>>>>> etc
>>>>> 
>>>>> Whatever you do, if there isn’t enough size, the array grows dynamically. In the last
>>>>> example there was more than enough size, but we only copied  the 10 numbers
>>>>> we got.
>>>>> 
>>>>> I have added this type to OSClisten  and OSCsend2. 
>>>>> 
>>>>> ========================
>>>>> Prof. Victor Lazzarini
>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>> Maynooth University,
>>>>> Maynooth, Co Kildare, Ireland
>>>>> Tel: 00 353 7086936
>>>>> Fax: 00 353 1 7086952 
>>>>> 
>>>>>> On 6 Apr 2017, at 22:20, Guillermo Senna  wrote:
>>>>>> 
>>>>>> Oh, I see. And in the 2D version, if I send a single blob/array with:
>>>>>> 
>>>>>> 10 elements -> they all end up in dimension no. 1
>>>>>> 
>>>>>> 30 elements -> they'd go 16-14
>>>>>> 
>>>>>> 40 elements -> 16-24
>>>>>> 
>>>>>> Or is it going to be an error not to match the dimensions/sizes?
>>>>>> 
>>>>>>> On 06/04/17 18:10, Victor Lazzarini wrote:
>>>>>>> No, I mean
>>>>>>> 
>>>>>>> kArr[][] init 2, 16
>>>>>>> kk1  OSClisten gihandle, "/multiArr", "D", kArr
>>>>>>> 
>>>>>>> or
>>>>>>> 
>>>>>>> kArr[] init 32
>>>>>>> kk1  OSClisten gihandle, "/multiArr", "D", kArr
>>>>>>> 
>>>>>>> both working, the choice is yours
>>>>>>> 
>>>>>>> 
>>>>>>> ========================
>>>>>>> Prof. Victor Lazzarini
>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>> Maynooth University,
>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>> Tel: 00 353 7086936
>>>>>>> Fax: 00 353 1 7086952 
>>>>>>> 
>>>>>>>> On 6 Apr 2017, at 21:46, Guillermo Senna  wrote:
>>>>>>>> 
>>>>>>>> I'm not so sure I follow you with that last sentence. Do you mean
>>>>>>>> something like this could be possible?
>>>>>>>> 
>>>>>>>> kArr[][] init 2, 16
>>>>>>>> kk1  OSClisten gihandle, "/multiArr", "DD", kArr[0], kArr[1]
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On 06/04/17 17:36, Victor Lazzarini wrote:
>>>>>>>>> yes, same thing from the user perspective. Except that you can define how many dimensions you want
>>>>>>>>> to hold the data in.
>>>>>>>>> ========================
>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>> Maynooth University,
>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>> 
>>>>>>>>>> On 6 Apr 2017, at 21:33, Guillermo Senna  wrote:
>>>>>>>>>> 
>>>>>>>>>> I like that. Non of those characters are really part of the OSC
>>>>>>>>>> specification, so why not?
>>>>>>>>>> 
>>>>>>>>>> But with this approach you would still use a Csound array as xdata1 in
>>>>>>>>>> OSClisten, right?
>>>>>>>>>> 
>>>>>>>>>>> On 06/04/17 17:16, Victor Lazzarini wrote:
>>>>>>>>>>> We could put in a different type name for non-descript double-format data sequence (e.g. 2), for instance
>>>>>>>>>>> call it “D”.
>>>>>>>>>>> ========================
>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>> Maynooth University,
>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>> 
>>>>>>>>>>>> On 6 Apr 2017, at 21:04, Guillermo Senna  wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> I've not considered number 2 before. How about adding an opcode later
>>>>>>>>>>>> for joining 2d arrays into a single multidimensional? Would it be to
>>>>>>>>>>>> difficult/inefficient to do that considering that in the end it's all
>>>>>>>>>>>> about pointers?
>>>>>>>>>>>> 
>>>>>>>>>>>> I don't want to change and break it for others already using the current
>>>>>>>>>>>> structure.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>> On 05/04/17 18:12, Victor Lazzarini wrote:
>>>>>>>>>>>>> I see what you mean. It’s possible to change it, there are two options:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 1) encode everything with doubles
>>>>>>>>>>>>> 2) leave dim and size. The size of the blob is always there before the
>>>>>>>>>>>>> data, so we can just use that. It will be then up to the user to interpret
>>>>>>>>>>>>> the data as a 1,2,3 ,… dimensional array. The data is always stored
>>>>>>>>>>>>> as a flat vector (e.g. row-column for 2-d).
>>>>>>>>>>>>> 
>>>>>>>>>>>>> if people want it changed, I can do it.
>>>>>>>>>>>>> ========================
>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On 5 Apr 2017, at 18:24, Guillermo Senna  wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> My reasoning is that in the different programming languages you'd use a
>>>>>>>>>>>>>> library/module for handling the OSC part and that would in turn have
>>>>>>>>>>>>>> some abstraction for sending entire arrays as blobs. Now, Csound
>>>>>>>>>>>>>> requests for two 32-bit ints and then the rest 64-bits doubles. Is that
>>>>>>>>>>>>>> always possible to control in the higher-level languages?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Initially what I'd have thought is that I could build an array with all
>>>>>>>>>>>>>> doubles and Csound would internally truncate the first two values and
>>>>>>>>>>>>>> cast them into ints.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> But if it's working for everyone right now nothing should be changed!
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On 05/04/17 14:04, Victor Lazzarini wrote:
>>>>>>>>>>>>>>> Well, Csound reads two ints, as far as I can see. So I would expect that you can just send two
>>>>>>>>>>>>>>> separate ints and Csound would understand it (first the dimension, then the size). This is
>>>>>>>>>>>>>>> what OSCsend2 (& OSCsend) does. Not quite sure what might be going on at your end.
>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On 5 Apr 2017, at 17:44, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Well I'm doing it in C++ with oscpack and for me it works. Now, I don't
>>>>>>>>>>>>>>>> know much about python for example, but if you are using a python module
>>>>>>>>>>>>>>>> for handling the OSC part of your program, is it possible to construct
>>>>>>>>>>>>>>>> the array to be sent as two ints and the rest as doubles?
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> I'm asking from complete ignorance, Victor. It just seemed odd to
>>>>>>>>>>>>>>>> (instead of passing my entire vector in C++) have to do something like this:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> unsigned long ui = qvlist.size();
>>>>>>>>>>>>>>>> ui <<= 32; ui |= 1;
>>>>>>>>>>>>>>>> vec.push_back (*(double*)&ui);
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On 05/04/17 13:30, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>> I have implemented the array, audio and function table as per OSCsend/OSClisten. As far as I can see from the code, the blob is as you
>>>>>>>>>>>>>>>>> describe, all data being sent in the native endianess (little endian for i386/x86_64). It could be that the OSC lib is expecting the data
>>>>>>>>>>>>>>>>> in big-endian ints, 4 bytes at a time. As far as I understand, the OSC should not impose any particular interpretation to the blob,
>>>>>>>>>>>>>>>>> but just take it as a string of bytes.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On 5 Apr 2017, at 17:03, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> I'll try it in a few moments. Are you going to replace OSClisten too? If
>>>>>>>>>>>>>>>>>> you do, please beware that right now receiving an array in Csound
>>>>>>>>>>>>>>>>>> expects the structure [dimensions(int); size(int); values(double)...]. I
>>>>>>>>>>>>>>>>>> had to bitshift and cast two ints as a double in order to make that work
>>>>>>>>>>>>>>>>>> from a third-party OSC library outside Csound. It didn't seem right and
>>>>>>>>>>>>>>>>>> I don't think it's possible in every programming language.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Cheers.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> On 05/04/17 08:30, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>>> Following our conclusion that liblo seems to be overly heavy weight for OSC sending, I have
>>>>>>>>>>>>>>>>>>> implemented an alternative version that uses UDP sockets directly. It is currently called
>>>>>>>>>>>>>>>>>>> OSCsend2 and the interface is exactly the same to OSCsend. In our tests, it appears to
>>>>>>>>>>>>>>>>>>> do the job, but have not tested it extensively.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> It has been suggested to remove OSCsend and replace it with OSCsend2, so I would
>>>>>>>>>>>>>>>>>>> like to check if OSCsend users could test OSCsend2 and let us know if there are differences
>>>>>>>>>>>>>>>>>>> and whether it works OK for you. We would also then like to know whether having
>>>>>>>>>>>>>>>>>>> OSCsend2 alongside OSCsend is your preference, or whether we should just replace it.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>  https://github.com/csound/csound/issues
>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>  https://github.com/csound/csound/issues
>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>> Csound mailing list
>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>   https://github.com/csound/csound/issues
>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>> Csound mailing list
>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>> Send bugs reports to
>>>>>>>>>>   https://github.com/csound/csound/issues
>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>> Csound mailing list
>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>> Send bugs reports to
>>>>>>>>>    https://github.com/csound/csound/issues
>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>> Csound mailing list
>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>> Send bugs reports to
>>>>>>>>    https://github.com/csound/csound/issues
>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>> Csound mailing list
>>>>>>> Csound@listserv.heanet.ie
>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>> Send bugs reports to
>>>>>>>     https://github.com/csound/csound/issues
>>>>>>> Discussions of bugs and features can be posted here
>>>>>> Csound mailing list
>>>>>> Csound@listserv.heanet.ie
>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>> Send bugs reports to
>>>>>>     https://github.com/csound/csound/issues
>>>>>> Discussions of bugs and features can be posted here
>>>>> Csound mailing list
>>>>> Csound@listserv.heanet.ie
>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>> Send bugs reports to
>>>>>      https://github.com/csound/csound/issues
>>>>> Discussions of bugs and features can be posted here
>>>> Csound mailing list
>>>> Csound@listserv.heanet.ie
>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>> Send bugs reports to
>>>>      https://github.com/csound/csound/issues
>>>> Discussions of bugs and features can be posted here
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>       https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>> 
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>        https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
> 
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Ok, I had things back to front. Now it should work as I planned. The first dimension of the array changes,
not the lower ones. By first dimension I mean the columns in a row-column, ie. counting in the order in which the
indexes appear from right to left.
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 7 Apr 2017, at 08:02, Victor Lazzarini  wrote:
> 
> yes, I think I am mixing up dimension sizes, I will look. In any case, I will only be able to make one of the dimensions grow (as I can't guess how the matrix/cube/etc grows), whilst keeping the others fixed.
> 
> Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy
> Maynooth University
> Ireland
> 
>> On 7 Apr 2017, at 07:40, Guillermo Senna  wrote:
>> 
>> If I send a unidimensional array (from inside or outside Csound) it does
>> grow organically!
>> 
>> 
>>> On 07/04/17 02:39, Victor Lazzarini wrote:
>>> It should be fixed now. The array was growing but I forgot to update the sizes.
>>> ========================
>>> Prof. Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy,
>>> Maynooth University,
>>> Maynooth, Co Kildare, Ireland
>>> Tel: 00 353 7086936
>>> Fax: 00 353 1 7086952 
>>> 
>>>> On 7 Apr 2017, at 06:16, Victor Lazzarini  wrote:
>>>> 
>>>> That shouldn't happen, the array should grow. I'll have a look and fix it.
>>>> 
>>>> Victor Lazzarini
>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>> Maynooth University
>>>> Ireland
>>>> 
>>>>> On 7 Apr 2017, at 04:30, Guillermo Senna  wrote:
>>>>> 
>>>>> I tested the new specifier from outside Csound. Now I understand what
>>>>> you mean Victor. The good thing is that it forces you to choose a common
>>>>> size between sender and receiver in advance and that prevents you from
>>>>> getting "osc::OutOfBufferMemoryException" while sending exceedingly
>>>>> large vectors. The bad thing is the need to process the received array
>>>>> and look for a delimiter while sending variable-sized arrays like I'm
>>>>> doing. Or maybe I can just send the size before through "/kArrSize" or
>>>>> something like that.
>>>>> 
>>>>> Just for the record, with the "A" specifier you can do "kArr[] init 1"
>>>>> and the array will still grow and shrink dynamically according to
>>>>> dimensions/sizes received. That is very convenient. With the "D"
>>>>> specifier you get "Array index 2 out of range (0,0) for dimension 1".
>>>>> 
>>>>> I've to think now how to effectively process the received the array, but
>>>>> I think you saved me from a difficult-to-diagnose bug that I'd probably
>>>>> have encountered in the future because of the UDP protocol.
>>>>> 
>>>>> I'll test OSCsend2 now. Cheers.
>>>>> 
>>>>> 
>>>>>> On 06/04/17 18:33, Victor Lazzarini wrote:
>>>>>> Say you send 10 elements.
>>>>>> 
>>>>>> You can interpret this as
>>>>>> 
>>>>>> [1,2,3,4,5,6,7,8,9,10]
>>>>>> 
>>>>>> or
>>>>>> 
>>>>>> [1,2]
>>>>>> [3,4]
>>>>>> [5,6]
>>>>>> [7,8]
>>>>>> 
>>>>>> or
>>>>>> 
>>>>>> [1,2,3,4,5]
>>>>>> [6,7,8,9,10]
>>>>>> 
>>>>>> or
>>>>>> 
>>>>>> [1,2,3]
>>>>>> [4,5,6]
>>>>>> [7,8,9]
>>>>>> [10,0,0]
>>>>>> 
>>>>>> etc
>>>>>> 
>>>>>> Whatever you do, if there isn’t enough size, the array grows dynamically. In the last
>>>>>> example there was more than enough size, but we only copied  the 10 numbers
>>>>>> we got.
>>>>>> 
>>>>>> I have added this type to OSClisten  and OSCsend2. 
>>>>>> 
>>>>>> ========================
>>>>>> Prof. Victor Lazzarini
>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>> Maynooth University,
>>>>>> Maynooth, Co Kildare, Ireland
>>>>>> Tel: 00 353 7086936
>>>>>> Fax: 00 353 1 7086952 
>>>>>> 
>>>>>>> On 6 Apr 2017, at 22:20, Guillermo Senna  wrote:
>>>>>>> 
>>>>>>> Oh, I see. And in the 2D version, if I send a single blob/array with:
>>>>>>> 
>>>>>>> 10 elements -> they all end up in dimension no. 1
>>>>>>> 
>>>>>>> 30 elements -> they'd go 16-14
>>>>>>> 
>>>>>>> 40 elements -> 16-24
>>>>>>> 
>>>>>>> Or is it going to be an error not to match the dimensions/sizes?
>>>>>>> 
>>>>>>>> On 06/04/17 18:10, Victor Lazzarini wrote:
>>>>>>>> No, I mean
>>>>>>>> 
>>>>>>>> kArr[][] init 2, 16
>>>>>>>> kk1  OSClisten gihandle, "/multiArr", "D", kArr
>>>>>>>> 
>>>>>>>> or
>>>>>>>> 
>>>>>>>> kArr[] init 32
>>>>>>>> kk1  OSClisten gihandle, "/multiArr", "D", kArr
>>>>>>>> 
>>>>>>>> both working, the choice is yours
>>>>>>>> 
>>>>>>>> 
>>>>>>>> ========================
>>>>>>>> Prof. Victor Lazzarini
>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>> Maynooth University,
>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>> Tel: 00 353 7086936
>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>> 
>>>>>>>>> On 6 Apr 2017, at 21:46, Guillermo Senna  wrote:
>>>>>>>>> 
>>>>>>>>> I'm not so sure I follow you with that last sentence. Do you mean
>>>>>>>>> something like this could be possible?
>>>>>>>>> 
>>>>>>>>> kArr[][] init 2, 16
>>>>>>>>> kk1  OSClisten gihandle, "/multiArr", "DD", kArr[0], kArr[1]
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> On 06/04/17 17:36, Victor Lazzarini wrote:
>>>>>>>>>> yes, same thing from the user perspective. Except that you can define how many dimensions you want
>>>>>>>>>> to hold the data in.
>>>>>>>>>> ========================
>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>> Maynooth University,
>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>> 
>>>>>>>>>>> On 6 Apr 2017, at 21:33, Guillermo Senna  wrote:
>>>>>>>>>>> 
>>>>>>>>>>> I like that. Non of those characters are really part of the OSC
>>>>>>>>>>> specification, so why not?
>>>>>>>>>>> 
>>>>>>>>>>> But with this approach you would still use a Csound array as xdata1 in
>>>>>>>>>>> OSClisten, right?
>>>>>>>>>>> 
>>>>>>>>>>>> On 06/04/17 17:16, Victor Lazzarini wrote:
>>>>>>>>>>>> We could put in a different type name for non-descript double-format data sequence (e.g. 2), for instance
>>>>>>>>>>>> call it “D”.
>>>>>>>>>>>> ========================
>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>> 
>>>>>>>>>>>>> On 6 Apr 2017, at 21:04, Guillermo Senna  wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I've not considered number 2 before. How about adding an opcode later
>>>>>>>>>>>>> for joining 2d arrays into a single multidimensional? Would it be to
>>>>>>>>>>>>> difficult/inefficient to do that considering that in the end it's all
>>>>>>>>>>>>> about pointers?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I don't want to change and break it for others already using the current
>>>>>>>>>>>>> structure.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On 05/04/17 18:12, Victor Lazzarini wrote:
>>>>>>>>>>>>>> I see what you mean. It’s possible to change it, there are two options:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 1) encode everything with doubles
>>>>>>>>>>>>>> 2) leave dim and size. The size of the blob is always there before the
>>>>>>>>>>>>>> data, so we can just use that. It will be then up to the user to interpret
>>>>>>>>>>>>>> the data as a 1,2,3 ,… dimensional array. The data is always stored
>>>>>>>>>>>>>> as a flat vector (e.g. row-column for 2-d).
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> if people want it changed, I can do it.
>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On 5 Apr 2017, at 18:24, Guillermo Senna  wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> My reasoning is that in the different programming languages you'd use a
>>>>>>>>>>>>>>> library/module for handling the OSC part and that would in turn have
>>>>>>>>>>>>>>> some abstraction for sending entire arrays as blobs. Now, Csound
>>>>>>>>>>>>>>> requests for two 32-bit ints and then the rest 64-bits doubles. Is that
>>>>>>>>>>>>>>> always possible to control in the higher-level languages?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Initially what I'd have thought is that I could build an array with all
>>>>>>>>>>>>>>> doubles and Csound would internally truncate the first two values and
>>>>>>>>>>>>>>> cast them into ints.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> But if it's working for everyone right now nothing should be changed!
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On 05/04/17 14:04, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>> Well, Csound reads two ints, as far as I can see. So I would expect that you can just send two
>>>>>>>>>>>>>>>> separate ints and Csound would understand it (first the dimension, then the size). This is
>>>>>>>>>>>>>>>> what OSCsend2 (& OSCsend) does. Not quite sure what might be going on at your end.
>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On 5 Apr 2017, at 17:44, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Well I'm doing it in C++ with oscpack and for me it works. Now, I don't
>>>>>>>>>>>>>>>>> know much about python for example, but if you are using a python module
>>>>>>>>>>>>>>>>> for handling the OSC part of your program, is it possible to construct
>>>>>>>>>>>>>>>>> the array to be sent as two ints and the rest as doubles?
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> I'm asking from complete ignorance, Victor. It just seemed odd to
>>>>>>>>>>>>>>>>> (instead of passing my entire vector in C++) have to do something like this:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> unsigned long ui = qvlist.size();
>>>>>>>>>>>>>>>>> ui <<= 32; ui |= 1;
>>>>>>>>>>>>>>>>> vec.push_back (*(double*)&ui);
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On 05/04/17 13:30, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>> I have implemented the array, audio and function table as per OSCsend/OSClisten. As far as I can see from the code, the blob is as you
>>>>>>>>>>>>>>>>>> describe, all data being sent in the native endianess (little endian for i386/x86_64). It could be that the OSC lib is expecting the data
>>>>>>>>>>>>>>>>>> in big-endian ints, 4 bytes at a time. As far as I understand, the OSC should not impose any particular interpretation to the blob,
>>>>>>>>>>>>>>>>>> but just take it as a string of bytes.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> On 5 Apr 2017, at 17:03, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> I'll try it in a few moments. Are you going to replace OSClisten too? If
>>>>>>>>>>>>>>>>>>> you do, please beware that right now receiving an array in Csound
>>>>>>>>>>>>>>>>>>> expects the structure [dimensions(int); size(int); values(double)...]. I
>>>>>>>>>>>>>>>>>>> had to bitshift and cast two ints as a double in order to make that work
>>>>>>>>>>>>>>>>>>> from a third-party OSC library outside Csound. It didn't seem right and
>>>>>>>>>>>>>>>>>>> I don't think it's possible in every programming language.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Cheers.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> On 05/04/17 08:30, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>>>> Following our conclusion that liblo seems to be overly heavy weight for OSC sending, I have
>>>>>>>>>>>>>>>>>>>> implemented an alternative version that uses UDP sockets directly. It is currently called
>>>>>>>>>>>>>>>>>>>> OSCsend2 and the interface is exactly the same to OSCsend. In our tests, it appears to
>>>>>>>>>>>>>>>>>>>> do the job, but have not tested it extensively.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> It has been suggested to remove OSCsend and replace it with OSCsend2, so I would
>>>>>>>>>>>>>>>>>>>> like to check if OSCsend users could test OSCsend2 and let us know if there are differences
>>>>>>>>>>>>>>>>>>>> and whether it works OK for you. We would also then like to know whether having
>>>>>>>>>>>>>>>>>>>> OSCsend2 alongside OSCsend is your preference, or whether we should just replace it.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>  https://github.com/csound/csound/issues
>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>> Csound mailing list
>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>  https://github.com/csound/csound/issues
>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>> Csound mailing list
>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>> Send bugs reports to
>>>>>>>>>>   https://github.com/csound/csound/issues
>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>> Csound mailing list
>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>> Send bugs reports to
>>>>>>>>>   https://github.com/csound/csound/issues
>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>> Csound mailing list
>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>> Send bugs reports to
>>>>>>>>    https://github.com/csound/csound/issues
>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>> Csound mailing list
>>>>>>> Csound@listserv.heanet.ie
>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>> Send bugs reports to
>>>>>>>    https://github.com/csound/csound/issues
>>>>>>> Discussions of bugs and features can be posted here
>>>>>> Csound mailing list
>>>>>> Csound@listserv.heanet.ie
>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>> Send bugs reports to
>>>>>>     https://github.com/csound/csound/issues
>>>>>> Discussions of bugs and features can be posted here
>>>>> Csound mailing list
>>>>> Csound@listserv.heanet.ie
>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>> Send bugs reports to
>>>>>     https://github.com/csound/csound/issues
>>>>> Discussions of bugs and features can be posted here
>>>> Csound mailing list
>>>> Csound@listserv.heanet.ie
>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>> Send bugs reports to
>>>>      https://github.com/csound/csound/issues
>>>> Discussions of bugs and features can be posted here
>>> 
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>       https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>> 
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>       https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
> 
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here


Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I mean, not the higher ones!
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 7 Apr 2017, at 08:58, Victor Lazzarini  wrote:
> 
> Ok, I had things back to front. Now it should work as I planned. The first dimension of the array changes,
> not the lower ones. By first dimension I mean the columns in a row-column, ie. counting in the order in which the
> indexes appear from right to left.
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952 
> 
>> On 7 Apr 2017, at 08:02, Victor Lazzarini  wrote:
>> 
>> yes, I think I am mixing up dimension sizes, I will look. In any case, I will only be able to make one of the dimensions grow (as I can't guess how the matrix/cube/etc grows), whilst keeping the others fixed.
>> 
>> Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy
>> Maynooth University
>> Ireland
>> 
>>> On 7 Apr 2017, at 07:40, Guillermo Senna  wrote:
>>> 
>>> If I send a unidimensional array (from inside or outside Csound) it does
>>> grow organically!
>>> 
>>> 
>>>> On 07/04/17 02:39, Victor Lazzarini wrote:
>>>> It should be fixed now. The array was growing but I forgot to update the sizes.
>>>> ========================
>>>> Prof. Victor Lazzarini
>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>> Maynooth University,
>>>> Maynooth, Co Kildare, Ireland
>>>> Tel: 00 353 7086936
>>>> Fax: 00 353 1 7086952 
>>>> 
>>>>> On 7 Apr 2017, at 06:16, Victor Lazzarini  wrote:
>>>>> 
>>>>> That shouldn't happen, the array should grow. I'll have a look and fix it.
>>>>> 
>>>>> Victor Lazzarini
>>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>>> Maynooth University
>>>>> Ireland
>>>>> 
>>>>>> On 7 Apr 2017, at 04:30, Guillermo Senna  wrote:
>>>>>> 
>>>>>> I tested the new specifier from outside Csound. Now I understand what
>>>>>> you mean Victor. The good thing is that it forces you to choose a common
>>>>>> size between sender and receiver in advance and that prevents you from
>>>>>> getting "osc::OutOfBufferMemoryException" while sending exceedingly
>>>>>> large vectors. The bad thing is the need to process the received array
>>>>>> and look for a delimiter while sending variable-sized arrays like I'm
>>>>>> doing. Or maybe I can just send the size before through "/kArrSize" or
>>>>>> something like that.
>>>>>> 
>>>>>> Just for the record, with the "A" specifier you can do "kArr[] init 1"
>>>>>> and the array will still grow and shrink dynamically according to
>>>>>> dimensions/sizes received. That is very convenient. With the "D"
>>>>>> specifier you get "Array index 2 out of range (0,0) for dimension 1".
>>>>>> 
>>>>>> I've to think now how to effectively process the received the array, but
>>>>>> I think you saved me from a difficult-to-diagnose bug that I'd probably
>>>>>> have encountered in the future because of the UDP protocol.
>>>>>> 
>>>>>> I'll test OSCsend2 now. Cheers.
>>>>>> 
>>>>>> 
>>>>>>> On 06/04/17 18:33, Victor Lazzarini wrote:
>>>>>>> Say you send 10 elements.
>>>>>>> 
>>>>>>> You can interpret this as
>>>>>>> 
>>>>>>> [1,2,3,4,5,6,7,8,9,10]
>>>>>>> 
>>>>>>> or
>>>>>>> 
>>>>>>> [1,2]
>>>>>>> [3,4]
>>>>>>> [5,6]
>>>>>>> [7,8]
>>>>>>> 
>>>>>>> or
>>>>>>> 
>>>>>>> [1,2,3,4,5]
>>>>>>> [6,7,8,9,10]
>>>>>>> 
>>>>>>> or
>>>>>>> 
>>>>>>> [1,2,3]
>>>>>>> [4,5,6]
>>>>>>> [7,8,9]
>>>>>>> [10,0,0]
>>>>>>> 
>>>>>>> etc
>>>>>>> 
>>>>>>> Whatever you do, if there isn’t enough size, the array grows dynamically. In the last
>>>>>>> example there was more than enough size, but we only copied  the 10 numbers
>>>>>>> we got.
>>>>>>> 
>>>>>>> I have added this type to OSClisten  and OSCsend2. 
>>>>>>> 
>>>>>>> ========================
>>>>>>> Prof. Victor Lazzarini
>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>> Maynooth University,
>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>> Tel: 00 353 7086936
>>>>>>> Fax: 00 353 1 7086952 
>>>>>>> 
>>>>>>>> On 6 Apr 2017, at 22:20, Guillermo Senna  wrote:
>>>>>>>> 
>>>>>>>> Oh, I see. And in the 2D version, if I send a single blob/array with:
>>>>>>>> 
>>>>>>>> 10 elements -> they all end up in dimension no. 1
>>>>>>>> 
>>>>>>>> 30 elements -> they'd go 16-14
>>>>>>>> 
>>>>>>>> 40 elements -> 16-24
>>>>>>>> 
>>>>>>>> Or is it going to be an error not to match the dimensions/sizes?
>>>>>>>> 
>>>>>>>>> On 06/04/17 18:10, Victor Lazzarini wrote:
>>>>>>>>> No, I mean
>>>>>>>>> 
>>>>>>>>> kArr[][] init 2, 16
>>>>>>>>> kk1  OSClisten gihandle, "/multiArr", "D", kArr
>>>>>>>>> 
>>>>>>>>> or
>>>>>>>>> 
>>>>>>>>> kArr[] init 32
>>>>>>>>> kk1  OSClisten gihandle, "/multiArr", "D", kArr
>>>>>>>>> 
>>>>>>>>> both working, the choice is yours
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> ========================
>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>> Maynooth University,
>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>> 
>>>>>>>>>> On 6 Apr 2017, at 21:46, Guillermo Senna  wrote:
>>>>>>>>>> 
>>>>>>>>>> I'm not so sure I follow you with that last sentence. Do you mean
>>>>>>>>>> something like this could be possible?
>>>>>>>>>> 
>>>>>>>>>> kArr[][] init 2, 16
>>>>>>>>>> kk1  OSClisten gihandle, "/multiArr", "DD", kArr[0], kArr[1]
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> On 06/04/17 17:36, Victor Lazzarini wrote:
>>>>>>>>>>> yes, same thing from the user perspective. Except that you can define how many dimensions you want
>>>>>>>>>>> to hold the data in.
>>>>>>>>>>> ========================
>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>> Maynooth University,
>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>> 
>>>>>>>>>>>> On 6 Apr 2017, at 21:33, Guillermo Senna  wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> I like that. Non of those characters are really part of the OSC
>>>>>>>>>>>> specification, so why not?
>>>>>>>>>>>> 
>>>>>>>>>>>> But with this approach you would still use a Csound array as xdata1 in
>>>>>>>>>>>> OSClisten, right?
>>>>>>>>>>>> 
>>>>>>>>>>>>> On 06/04/17 17:16, Victor Lazzarini wrote:
>>>>>>>>>>>>> We could put in a different type name for non-descript double-format data sequence (e.g. 2), for instance
>>>>>>>>>>>>> call it “D”.
>>>>>>>>>>>>> ========================
>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On 6 Apr 2017, at 21:04, Guillermo Senna  wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I've not considered number 2 before. How about adding an opcode later
>>>>>>>>>>>>>> for joining 2d arrays into a single multidimensional? Would it be to
>>>>>>>>>>>>>> difficult/inefficient to do that considering that in the end it's all
>>>>>>>>>>>>>> about pointers?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I don't want to change and break it for others already using the current
>>>>>>>>>>>>>> structure.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On 05/04/17 18:12, Victor Lazzarini wrote:
>>>>>>>>>>>>>>> I see what you mean. It’s possible to change it, there are two options:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 1) encode everything with doubles
>>>>>>>>>>>>>>> 2) leave dim and size. The size of the blob is always there before the
>>>>>>>>>>>>>>> data, so we can just use that. It will be then up to the user to interpret
>>>>>>>>>>>>>>> the data as a 1,2,3 ,… dimensional array. The data is always stored
>>>>>>>>>>>>>>> as a flat vector (e.g. row-column for 2-d).
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> if people want it changed, I can do it.
>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On 5 Apr 2017, at 18:24, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> My reasoning is that in the different programming languages you'd use a
>>>>>>>>>>>>>>>> library/module for handling the OSC part and that would in turn have
>>>>>>>>>>>>>>>> some abstraction for sending entire arrays as blobs. Now, Csound
>>>>>>>>>>>>>>>> requests for two 32-bit ints and then the rest 64-bits doubles. Is that
>>>>>>>>>>>>>>>> always possible to control in the higher-level languages?
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Initially what I'd have thought is that I could build an array with all
>>>>>>>>>>>>>>>> doubles and Csound would internally truncate the first two values and
>>>>>>>>>>>>>>>> cast them into ints.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> But if it's working for everyone right now nothing should be changed!
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On 05/04/17 14:04, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>> Well, Csound reads two ints, as far as I can see. So I would expect that you can just send two
>>>>>>>>>>>>>>>>> separate ints and Csound would understand it (first the dimension, then the size). This is
>>>>>>>>>>>>>>>>> what OSCsend2 (& OSCsend) does. Not quite sure what might be going on at your end.
>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On 5 Apr 2017, at 17:44, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Well I'm doing it in C++ with oscpack and for me it works. Now, I don't
>>>>>>>>>>>>>>>>>> know much about python for example, but if you are using a python module
>>>>>>>>>>>>>>>>>> for handling the OSC part of your program, is it possible to construct
>>>>>>>>>>>>>>>>>> the array to be sent as two ints and the rest as doubles?
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> I'm asking from complete ignorance, Victor. It just seemed odd to
>>>>>>>>>>>>>>>>>> (instead of passing my entire vector in C++) have to do something like this:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> unsigned long ui = qvlist.size();
>>>>>>>>>>>>>>>>>> ui <<= 32; ui |= 1;
>>>>>>>>>>>>>>>>>> vec.push_back (*(double*)&ui);
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> On 05/04/17 13:30, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>>> I have implemented the array, audio and function table as per OSCsend/OSClisten. As far as I can see from the code, the blob is as you
>>>>>>>>>>>>>>>>>>> describe, all data being sent in the native endianess (little endian for i386/x86_64). It could be that the OSC lib is expecting the data
>>>>>>>>>>>>>>>>>>> in big-endian ints, 4 bytes at a time. As far as I understand, the OSC should not impose any particular interpretation to the blob,
>>>>>>>>>>>>>>>>>>> but just take it as a string of bytes.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> On 5 Apr 2017, at 17:03, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> I'll try it in a few moments. Are you going to replace OSClisten too? If
>>>>>>>>>>>>>>>>>>>> you do, please beware that right now receiving an array in Csound
>>>>>>>>>>>>>>>>>>>> expects the structure [dimensions(int); size(int); values(double)...]. I
>>>>>>>>>>>>>>>>>>>> had to bitshift and cast two ints as a double in order to make that work
>>>>>>>>>>>>>>>>>>>> from a third-party OSC library outside Csound. It didn't seem right and
>>>>>>>>>>>>>>>>>>>> I don't think it's possible in every programming language.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Cheers.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> On 05/04/17 08:30, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>>>>> Following our conclusion that liblo seems to be overly heavy weight for OSC sending, I have
>>>>>>>>>>>>>>>>>>>>> implemented an alternative version that uses UDP sockets directly. It is currently called
>>>>>>>>>>>>>>>>>>>>> OSCsend2 and the interface is exactly the same to OSCsend. In our tests, it appears to
>>>>>>>>>>>>>>>>>>>>> do the job, but have not tested it extensively.
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> It has been suggested to remove OSCsend and replace it with OSCsend2, so I would
>>>>>>>>>>>>>>>>>>>>> like to check if OSCsend users could test OSCsend2 and let us know if there are differences
>>>>>>>>>>>>>>>>>>>>> and whether it works OK for you. We would also then like to know whether having
>>>>>>>>>>>>>>>>>>>>> OSCsend2 alongside OSCsend is your preference, or whether we should just replace it.
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>> Csound mailing list
>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>  https://github.com/csound/csound/issues
>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>> Csound mailing list
>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>> Send bugs reports to
>>>>>>>>>>  https://github.com/csound/csound/issues
>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>> Csound mailing list
>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>> Send bugs reports to
>>>>>>>>>   https://github.com/csound/csound/issues
>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>> Csound mailing list
>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>> Send bugs reports to
>>>>>>>>   https://github.com/csound/csound/issues
>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>> Csound mailing list
>>>>>>> Csound@listserv.heanet.ie
>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>> Send bugs reports to
>>>>>>>    https://github.com/csound/csound/issues
>>>>>>> Discussions of bugs and features can be posted here
>>>>>> Csound mailing list
>>>>>> Csound@listserv.heanet.ie
>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>> Send bugs reports to
>>>>>>    https://github.com/csound/csound/issues
>>>>>> Discussions of bugs and features can be posted here
>>>>> Csound mailing list
>>>>> Csound@listserv.heanet.ie
>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>> Send bugs reports to
>>>>>     https://github.com/csound/csound/issues
>>>>> Discussions of bugs and features can be posted here
>>>> 
>>>> Csound mailing list
>>>> Csound@listserv.heanet.ie
>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>> Send bugs reports to
>>>>      https://github.com/csound/csound/issues
>>>> Discussions of bugs and features can be posted here
>>> 
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>      https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>> 
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>       https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
> 
> 
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here


Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I'm getting the same thing, Victor.  Could you try the test files I'm
using? Maybe I'm expecting something that's not even possible.


On 07/04/17 05:00, Victor Lazzarini wrote:
> I mean, not the higher ones!
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952 
>
>> On 7 Apr 2017, at 08:58, Victor Lazzarini  wrote:
>>
>> Ok, I had things back to front. Now it should work as I planned. The first dimension of the array changes,
>> not the lower ones. By first dimension I mean the columns in a row-column, ie. counting in the order in which the
>> indexes appear from right to left.
>> ========================
>> Prof. Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy,
>> Maynooth University,
>> Maynooth, Co Kildare, Ireland
>> Tel: 00 353 7086936
>> Fax: 00 353 1 7086952 
>>
>>> On 7 Apr 2017, at 08:02, Victor Lazzarini  wrote:
>>>
>>> yes, I think I am mixing up dimension sizes, I will look. In any case, I will only be able to make one of the dimensions grow (as I can't guess how the matrix/cube/etc grows), whilst keeping the others fixed.
>>>
>>> Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy
>>> Maynooth University
>>> Ireland
>>>
>>>> On 7 Apr 2017, at 07:40, Guillermo Senna  wrote:
>>>>
>>>> If I send a unidimensional array (from inside or outside Csound) it does
>>>> grow organically!
>>>>
>>>>
>>>>> On 07/04/17 02:39, Victor Lazzarini wrote:
>>>>> It should be fixed now. The array was growing but I forgot to update the sizes.
>>>>> ========================
>>>>> Prof. Victor Lazzarini
>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>> Maynooth University,
>>>>> Maynooth, Co Kildare, Ireland
>>>>> Tel: 00 353 7086936
>>>>> Fax: 00 353 1 7086952 
>>>>>
>>>>>> On 7 Apr 2017, at 06:16, Victor Lazzarini  wrote:
>>>>>>
>>>>>> That shouldn't happen, the array should grow. I'll have a look and fix it.
>>>>>>
>>>>>> Victor Lazzarini
>>>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>>>> Maynooth University
>>>>>> Ireland
>>>>>>
>>>>>>> On 7 Apr 2017, at 04:30, Guillermo Senna  wrote:
>>>>>>>
>>>>>>> I tested the new specifier from outside Csound. Now I understand what
>>>>>>> you mean Victor. The good thing is that it forces you to choose a common
>>>>>>> size between sender and receiver in advance and that prevents you from
>>>>>>> getting "osc::OutOfBufferMemoryException" while sending exceedingly
>>>>>>> large vectors. The bad thing is the need to process the received array
>>>>>>> and look for a delimiter while sending variable-sized arrays like I'm
>>>>>>> doing. Or maybe I can just send the size before through "/kArrSize" or
>>>>>>> something like that.
>>>>>>>
>>>>>>> Just for the record, with the "A" specifier you can do "kArr[] init 1"
>>>>>>> and the array will still grow and shrink dynamically according to
>>>>>>> dimensions/sizes received. That is very convenient. With the "D"
>>>>>>> specifier you get "Array index 2 out of range (0,0) for dimension 1".
>>>>>>>
>>>>>>> I've to think now how to effectively process the received the array, but
>>>>>>> I think you saved me from a difficult-to-diagnose bug that I'd probably
>>>>>>> have encountered in the future because of the UDP protocol.
>>>>>>>
>>>>>>> I'll test OSCsend2 now. Cheers.
>>>>>>>
>>>>>>>
>>>>>>>> On 06/04/17 18:33, Victor Lazzarini wrote:
>>>>>>>> Say you send 10 elements.
>>>>>>>>
>>>>>>>> You can interpret this as
>>>>>>>>
>>>>>>>> [1,2,3,4,5,6,7,8,9,10]
>>>>>>>>
>>>>>>>> or
>>>>>>>>
>>>>>>>> [1,2]
>>>>>>>> [3,4]
>>>>>>>> [5,6]
>>>>>>>> [7,8]
>>>>>>>>
>>>>>>>> or
>>>>>>>>
>>>>>>>> [1,2,3,4,5]
>>>>>>>> [6,7,8,9,10]
>>>>>>>>
>>>>>>>> or
>>>>>>>>
>>>>>>>> [1,2,3]
>>>>>>>> [4,5,6]
>>>>>>>> [7,8,9]
>>>>>>>> [10,0,0]
>>>>>>>>
>>>>>>>> etc
>>>>>>>>
>>>>>>>> Whatever you do, if there isn’t enough size, the array grows dynamically. In the last
>>>>>>>> example there was more than enough size, but we only copied  the 10 numbers
>>>>>>>> we got.
>>>>>>>>
>>>>>>>> I have added this type to OSClisten  and OSCsend2. 
>>>>>>>>
>>>>>>>> ========================
>>>>>>>> Prof. Victor Lazzarini
>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>> Maynooth University,
>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>> Tel: 00 353 7086936
>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>
>>>>>>>>> On 6 Apr 2017, at 22:20, Guillermo Senna  wrote:
>>>>>>>>>
>>>>>>>>> Oh, I see. And in the 2D version, if I send a single blob/array with:
>>>>>>>>>
>>>>>>>>> 10 elements -> they all end up in dimension no. 1
>>>>>>>>>
>>>>>>>>> 30 elements -> they'd go 16-14
>>>>>>>>>
>>>>>>>>> 40 elements -> 16-24
>>>>>>>>>
>>>>>>>>> Or is it going to be an error not to match the dimensions/sizes?
>>>>>>>>>
>>>>>>>>>> On 06/04/17 18:10, Victor Lazzarini wrote:
>>>>>>>>>> No, I mean
>>>>>>>>>>
>>>>>>>>>> kArr[][] init 2, 16
>>>>>>>>>> kk1  OSClisten gihandle, "/multiArr", "D", kArr
>>>>>>>>>>
>>>>>>>>>> or
>>>>>>>>>>
>>>>>>>>>> kArr[] init 32
>>>>>>>>>> kk1  OSClisten gihandle, "/multiArr", "D", kArr
>>>>>>>>>>
>>>>>>>>>> both working, the choice is yours
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ========================
>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>> Maynooth University,
>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>
>>>>>>>>>>> On 6 Apr 2017, at 21:46, Guillermo Senna  wrote:
>>>>>>>>>>>
>>>>>>>>>>> I'm not so sure I follow you with that last sentence. Do you mean
>>>>>>>>>>> something like this could be possible?
>>>>>>>>>>>
>>>>>>>>>>> kArr[][] init 2, 16
>>>>>>>>>>> kk1  OSClisten gihandle, "/multiArr", "DD", kArr[0], kArr[1]
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> On 06/04/17 17:36, Victor Lazzarini wrote:
>>>>>>>>>>>> yes, same thing from the user perspective. Except that you can define how many dimensions you want
>>>>>>>>>>>> to hold the data in.
>>>>>>>>>>>> ========================
>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>
>>>>>>>>>>>>> On 6 Apr 2017, at 21:33, Guillermo Senna  wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> I like that. Non of those characters are really part of the OSC
>>>>>>>>>>>>> specification, so why not?
>>>>>>>>>>>>>
>>>>>>>>>>>>> But with this approach you would still use a Csound array as xdata1 in
>>>>>>>>>>>>> OSClisten, right?
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 06/04/17 17:16, Victor Lazzarini wrote:
>>>>>>>>>>>>>> We could put in a different type name for non-descript double-format data sequence (e.g. 2), for instance
>>>>>>>>>>>>>> call it “D”.
>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 6 Apr 2017, at 21:04, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I've not considered number 2 before. How about adding an opcode later
>>>>>>>>>>>>>>> for joining 2d arrays into a single multidimensional? Would it be to
>>>>>>>>>>>>>>> difficult/inefficient to do that considering that in the end it's all
>>>>>>>>>>>>>>> about pointers?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I don't want to change and break it for others already using the current
>>>>>>>>>>>>>>> structure.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 05/04/17 18:12, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>> I see what you mean. It’s possible to change it, there are two options:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 1) encode everything with doubles
>>>>>>>>>>>>>>>> 2) leave dim and size. The size of the blob is always there before the
>>>>>>>>>>>>>>>> data, so we can just use that. It will be then up to the user to interpret
>>>>>>>>>>>>>>>> the data as a 1,2,3 ,… dimensional array. The data is always stored
>>>>>>>>>>>>>>>> as a flat vector (e.g. row-column for 2-d).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> if people want it changed, I can do it.
>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 5 Apr 2017, at 18:24, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> My reasoning is that in the different programming languages you'd use a
>>>>>>>>>>>>>>>>> library/module for handling the OSC part and that would in turn have
>>>>>>>>>>>>>>>>> some abstraction for sending entire arrays as blobs. Now, Csound
>>>>>>>>>>>>>>>>> requests for two 32-bit ints and then the rest 64-bits doubles. Is that
>>>>>>>>>>>>>>>>> always possible to control in the higher-level languages?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Initially what I'd have thought is that I could build an array with all
>>>>>>>>>>>>>>>>> doubles and Csound would internally truncate the first two values and
>>>>>>>>>>>>>>>>> cast them into ints.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> But if it's working for everyone right now nothing should be changed!
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 05/04/17 14:04, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>> Well, Csound reads two ints, as far as I can see. So I would expect that you can just send two
>>>>>>>>>>>>>>>>>> separate ints and Csound would understand it (first the dimension, then the size). This is
>>>>>>>>>>>>>>>>>> what OSCsend2 (& OSCsend) does. Not quite sure what might be going on at your end.
>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 5 Apr 2017, at 17:44, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Well I'm doing it in C++ with oscpack and for me it works. Now, I don't
>>>>>>>>>>>>>>>>>>> know much about python for example, but if you are using a python module
>>>>>>>>>>>>>>>>>>> for handling the OSC part of your program, is it possible to construct
>>>>>>>>>>>>>>>>>>> the array to be sent as two ints and the rest as doubles?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I'm asking from complete ignorance, Victor. It just seemed odd to
>>>>>>>>>>>>>>>>>>> (instead of passing my entire vector in C++) have to do something like this:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> unsigned long ui = qvlist.size();
>>>>>>>>>>>>>>>>>>> ui <<= 32; ui |= 1;
>>>>>>>>>>>>>>>>>>> vec.push_back (*(double*)&ui);
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 05/04/17 13:30, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>>>> I have implemented the array, audio and function table as per OSCsend/OSClisten. As far as I can see from the code, the blob is as you
>>>>>>>>>>>>>>>>>>>> describe, all data being sent in the native endianess (little endian for i386/x86_64). It could be that the OSC lib is expecting the data
>>>>>>>>>>>>>>>>>>>> in big-endian ints, 4 bytes at a time. As far as I understand, the OSC should not impose any particular interpretation to the blob,
>>>>>>>>>>>>>>>>>>>> but just take it as a string of bytes.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 5 Apr 2017, at 17:03, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I'll try it in a few moments. Are you going to replace OSClisten too? If
>>>>>>>>>>>>>>>>>>>>> you do, please beware that right now receiving an array in Csound
>>>>>>>>>>>>>>>>>>>>> expects the structure [dimensions(int); size(int); values(double)...]. I
>>>>>>>>>>>>>>>>>>>>> had to bitshift and cast two ints as a double in order to make that work
>>>>>>>>>>>>>>>>>>>>> from a third-party OSC library outside Csound. It didn't seem right and
>>>>>>>>>>>>>>>>>>>>> I don't think it's possible in every programming language.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Cheers.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 05/04/17 08:30, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>>>>>> Following our conclusion that liblo seems to be overly heavy weight for OSC sending, I have
>>>>>>>>>>>>>>>>>>>>>> implemented an alternative version that uses UDP sockets directly. It is currently called
>>>>>>>>>>>>>>>>>>>>>> OSCsend2 and the interface is exactly the same to OSCsend. In our tests, it appears to
>>>>>>>>>>>>>>>>>>>>>> do the job, but have not tested it extensively.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> It has been suggested to remove OSCsend and replace it with OSCsend2, so I would
>>>>>>>>>>>>>>>>>>>>>> like to check if OSCsend users could test OSCsend2 and let us know if there are differences
>>>>>>>>>>>>>>>>>>>>>> and whether it works OK for you. We would also then like to know whether having
>>>>>>>>>>>>>>>>>>>>>> OSCsend2 alongside OSCsend is your preference, or whether we should just replace it.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>  https://github.com/csound/csound/issues
>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>> Csound mailing list
>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>  https://github.com/csound/csound/issues
>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>> Csound mailing list
>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>> Send bugs reports to
>>>>>>>>>>   https://github.com/csound/csound/issues
>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>> Csound mailing list
>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>> Send bugs reports to
>>>>>>>>>   https://github.com/csound/csound/issues
>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>> Csound mailing list
>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>> Send bugs reports to
>>>>>>>>    https://github.com/csound/csound/issues
>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>> Csound mailing list
>>>>>>> Csound@listserv.heanet.ie
>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>> Send bugs reports to
>>>>>>>    https://github.com/csound/csound/issues
>>>>>>> Discussions of bugs and features can be posted here
>>>>>> Csound mailing list
>>>>>> Csound@listserv.heanet.ie
>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>> Send bugs reports to
>>>>>>     https://github.com/csound/csound/issues
>>>>>> Discussions of bugs and features can be posted here
>>>>> Csound mailing list
>>>>> Csound@listserv.heanet.ie
>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>> Send bugs reports to
>>>>>      https://github.com/csound/csound/issues
>>>>> Discussions of bugs and features can be posted here
>>>> Csound mailing list
>>>> Csound@listserv.heanet.ie
>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>> Send bugs reports to
>>>>      https://github.com/csound/csound/issues
>>>> Discussions of bugs and features can be posted here
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>       https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>>
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>        https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here


Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I tested here with a 2d array, with size 1 on each dimension, then passed an array with 4  numbers over OSC and dim 1 (number of columns) grew to accommodate it. I am away from the computer but when I have the chance I will post a test CSD.

Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy
Maynooth University
Ireland

> On 7 Apr 2017, at 19:27, Guillermo Senna  wrote:
> 
> I'm getting the same thing, Victor.  Could you try the test files I'm
> using? Maybe I'm expecting something that's not even possible.
> 
> 
>> On 07/04/17 05:00, Victor Lazzarini wrote:
>> I mean, not the higher ones!
>> ========================
>> Prof. Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy,
>> Maynooth University,
>> Maynooth, Co Kildare, Ireland
>> Tel: 00 353 7086936
>> Fax: 00 353 1 7086952 
>> 
>>> On 7 Apr 2017, at 08:58, Victor Lazzarini  wrote:
>>> 
>>> Ok, I had things back to front. Now it should work as I planned. The first dimension of the array changes,
>>> not the lower ones. By first dimension I mean the columns in a row-column, ie. counting in the order in which the
>>> indexes appear from right to left.
>>> ========================
>>> Prof. Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy,
>>> Maynooth University,
>>> Maynooth, Co Kildare, Ireland
>>> Tel: 00 353 7086936
>>> Fax: 00 353 1 7086952 
>>> 
>>>> On 7 Apr 2017, at 08:02, Victor Lazzarini  wrote:
>>>> 
>>>> yes, I think I am mixing up dimension sizes, I will look. In any case, I will only be able to make one of the dimensions grow (as I can't guess how the matrix/cube/etc grows), whilst keeping the others fixed.
>>>> 
>>>> Victor Lazzarini
>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>> Maynooth University
>>>> Ireland
>>>> 
>>>>> On 7 Apr 2017, at 07:40, Guillermo Senna  wrote:
>>>>> 
>>>>> If I send a unidimensional array (from inside or outside Csound) it does
>>>>> grow organically!
>>>>> 
>>>>> 
>>>>>> On 07/04/17 02:39, Victor Lazzarini wrote:
>>>>>> It should be fixed now. The array was growing but I forgot to update the sizes.
>>>>>> ========================
>>>>>> Prof. Victor Lazzarini
>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>> Maynooth University,
>>>>>> Maynooth, Co Kildare, Ireland
>>>>>> Tel: 00 353 7086936
>>>>>> Fax: 00 353 1 7086952 
>>>>>> 
>>>>>>> On 7 Apr 2017, at 06:16, Victor Lazzarini  wrote:
>>>>>>> 
>>>>>>> That shouldn't happen, the array should grow. I'll have a look and fix it.
>>>>>>> 
>>>>>>> Victor Lazzarini
>>>>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>>>>> Maynooth University
>>>>>>> Ireland
>>>>>>> 
>>>>>>>> On 7 Apr 2017, at 04:30, Guillermo Senna  wrote:
>>>>>>>> 
>>>>>>>> I tested the new specifier from outside Csound. Now I understand what
>>>>>>>> you mean Victor. The good thing is that it forces you to choose a common
>>>>>>>> size between sender and receiver in advance and that prevents you from
>>>>>>>> getting "osc::OutOfBufferMemoryException" while sending exceedingly
>>>>>>>> large vectors. The bad thing is the need to process the received array
>>>>>>>> and look for a delimiter while sending variable-sized arrays like I'm
>>>>>>>> doing. Or maybe I can just send the size before through "/kArrSize" or
>>>>>>>> something like that.
>>>>>>>> 
>>>>>>>> Just for the record, with the "A" specifier you can do "kArr[] init 1"
>>>>>>>> and the array will still grow and shrink dynamically according to
>>>>>>>> dimensions/sizes received. That is very convenient. With the "D"
>>>>>>>> specifier you get "Array index 2 out of range (0,0) for dimension 1".
>>>>>>>> 
>>>>>>>> I've to think now how to effectively process the received the array, but
>>>>>>>> I think you saved me from a difficult-to-diagnose bug that I'd probably
>>>>>>>> have encountered in the future because of the UDP protocol.
>>>>>>>> 
>>>>>>>> I'll test OSCsend2 now. Cheers.
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On 06/04/17 18:33, Victor Lazzarini wrote:
>>>>>>>>> Say you send 10 elements.
>>>>>>>>> 
>>>>>>>>> You can interpret this as
>>>>>>>>> 
>>>>>>>>> [1,2,3,4,5,6,7,8,9,10]
>>>>>>>>> 
>>>>>>>>> or
>>>>>>>>> 
>>>>>>>>> [1,2]
>>>>>>>>> [3,4]
>>>>>>>>> [5,6]
>>>>>>>>> [7,8]
>>>>>>>>> 
>>>>>>>>> or
>>>>>>>>> 
>>>>>>>>> [1,2,3,4,5]
>>>>>>>>> [6,7,8,9,10]
>>>>>>>>> 
>>>>>>>>> or
>>>>>>>>> 
>>>>>>>>> [1,2,3]
>>>>>>>>> [4,5,6]
>>>>>>>>> [7,8,9]
>>>>>>>>> [10,0,0]
>>>>>>>>> 
>>>>>>>>> etc
>>>>>>>>> 
>>>>>>>>> Whatever you do, if there isn’t enough size, the array grows dynamically. In the last
>>>>>>>>> example there was more than enough size, but we only copied  the 10 numbers
>>>>>>>>> we got.
>>>>>>>>> 
>>>>>>>>> I have added this type to OSClisten  and OSCsend2. 
>>>>>>>>> 
>>>>>>>>> ========================
>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>> Maynooth University,
>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>> 
>>>>>>>>>> On 6 Apr 2017, at 22:20, Guillermo Senna  wrote:
>>>>>>>>>> 
>>>>>>>>>> Oh, I see. And in the 2D version, if I send a single blob/array with:
>>>>>>>>>> 
>>>>>>>>>> 10 elements -> they all end up in dimension no. 1
>>>>>>>>>> 
>>>>>>>>>> 30 elements -> they'd go 16-14
>>>>>>>>>> 
>>>>>>>>>> 40 elements -> 16-24
>>>>>>>>>> 
>>>>>>>>>> Or is it going to be an error not to match the dimensions/sizes?
>>>>>>>>>> 
>>>>>>>>>>> On 06/04/17 18:10, Victor Lazzarini wrote:
>>>>>>>>>>> No, I mean
>>>>>>>>>>> 
>>>>>>>>>>> kArr[][] init 2, 16
>>>>>>>>>>> kk1  OSClisten gihandle, "/multiArr", "D", kArr
>>>>>>>>>>> 
>>>>>>>>>>> or
>>>>>>>>>>> 
>>>>>>>>>>> kArr[] init 32
>>>>>>>>>>> kk1  OSClisten gihandle, "/multiArr", "D", kArr
>>>>>>>>>>> 
>>>>>>>>>>> both working, the choice is yours
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> ========================
>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>> Maynooth University,
>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>> 
>>>>>>>>>>>> On 6 Apr 2017, at 21:46, Guillermo Senna  wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> I'm not so sure I follow you with that last sentence. Do you mean
>>>>>>>>>>>> something like this could be possible?
>>>>>>>>>>>> 
>>>>>>>>>>>> kArr[][] init 2, 16
>>>>>>>>>>>> kk1  OSClisten gihandle, "/multiArr", "DD", kArr[0], kArr[1]
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>> On 06/04/17 17:36, Victor Lazzarini wrote:
>>>>>>>>>>>>> yes, same thing from the user perspective. Except that you can define how many dimensions you want
>>>>>>>>>>>>> to hold the data in.
>>>>>>>>>>>>> ========================
>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On 6 Apr 2017, at 21:33, Guillermo Senna  wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I like that. Non of those characters are really part of the OSC
>>>>>>>>>>>>>> specification, so why not?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> But with this approach you would still use a Csound array as xdata1 in
>>>>>>>>>>>>>> OSClisten, right?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On 06/04/17 17:16, Victor Lazzarini wrote:
>>>>>>>>>>>>>>> We could put in a different type name for non-descript double-format data sequence (e.g. 2), for instance
>>>>>>>>>>>>>>> call it “D”.
>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On 6 Apr 2017, at 21:04, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> I've not considered number 2 before. How about adding an opcode later
>>>>>>>>>>>>>>>> for joining 2d arrays into a single multidimensional? Would it be to
>>>>>>>>>>>>>>>> difficult/inefficient to do that considering that in the end it's all
>>>>>>>>>>>>>>>> about pointers?
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> I don't want to change and break it for others already using the current
>>>>>>>>>>>>>>>> structure.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On 05/04/17 18:12, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>> I see what you mean. It’s possible to change it, there are two options:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 1) encode everything with doubles
>>>>>>>>>>>>>>>>> 2) leave dim and size. The size of the blob is always there before the
>>>>>>>>>>>>>>>>> data, so we can just use that. It will be then up to the user to interpret
>>>>>>>>>>>>>>>>> the data as a 1,2,3 ,… dimensional array. The data is always stored
>>>>>>>>>>>>>>>>> as a flat vector (e.g. row-column for 2-d).
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> if people want it changed, I can do it.
>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On 5 Apr 2017, at 18:24, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> My reasoning is that in the different programming languages you'd use a
>>>>>>>>>>>>>>>>>> library/module for handling the OSC part and that would in turn have
>>>>>>>>>>>>>>>>>> some abstraction for sending entire arrays as blobs. Now, Csound
>>>>>>>>>>>>>>>>>> requests for two 32-bit ints and then the rest 64-bits doubles. Is that
>>>>>>>>>>>>>>>>>> always possible to control in the higher-level languages?
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Initially what I'd have thought is that I could build an array with all
>>>>>>>>>>>>>>>>>> doubles and Csound would internally truncate the first two values and
>>>>>>>>>>>>>>>>>> cast them into ints.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> But if it's working for everyone right now nothing should be changed!
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> On 05/04/17 14:04, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>>> Well, Csound reads two ints, as far as I can see. So I would expect that you can just send two
>>>>>>>>>>>>>>>>>>> separate ints and Csound would understand it (first the dimension, then the size). This is
>>>>>>>>>>>>>>>>>>> what OSCsend2 (& OSCsend) does. Not quite sure what might be going on at your end.
>>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> On 5 Apr 2017, at 17:44, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Well I'm doing it in C++ with oscpack and for me it works. Now, I don't
>>>>>>>>>>>>>>>>>>>> know much about python for example, but if you are using a python module
>>>>>>>>>>>>>>>>>>>> for handling the OSC part of your program, is it possible to construct
>>>>>>>>>>>>>>>>>>>> the array to be sent as two ints and the rest as doubles?
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> I'm asking from complete ignorance, Victor. It just seemed odd to
>>>>>>>>>>>>>>>>>>>> (instead of passing my entire vector in C++) have to do something like this:
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> unsigned long ui = qvlist.size();
>>>>>>>>>>>>>>>>>>>> ui <<= 32; ui |= 1;
>>>>>>>>>>>>>>>>>>>> vec.push_back (*(double*)&ui);
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> On 05/04/17 13:30, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>>>>> I have implemented the array, audio and function table as per OSCsend/OSClisten. As far as I can see from the code, the blob is as you
>>>>>>>>>>>>>>>>>>>>> describe, all data being sent in the native endianess (little endian for i386/x86_64). It could be that the OSC lib is expecting the data
>>>>>>>>>>>>>>>>>>>>> in big-endian ints, 4 bytes at a time. As far as I understand, the OSC should not impose any particular interpretation to the blob,
>>>>>>>>>>>>>>>>>>>>> but just take it as a string of bytes.
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> On 5 Apr 2017, at 17:03, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> I'll try it in a few moments. Are you going to replace OSClisten too? If
>>>>>>>>>>>>>>>>>>>>>> you do, please beware that right now receiving an array in Csound
>>>>>>>>>>>>>>>>>>>>>> expects the structure [dimensions(int); size(int); values(double)...]. I
>>>>>>>>>>>>>>>>>>>>>> had to bitshift and cast two ints as a double in order to make that work
>>>>>>>>>>>>>>>>>>>>>> from a third-party OSC library outside Csound. It didn't seem right and
>>>>>>>>>>>>>>>>>>>>>> I don't think it's possible in every programming language.
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> Cheers.
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> On 05/04/17 08:30, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>>>>>>> Following our conclusion that liblo seems to be overly heavy weight for OSC sending, I have
>>>>>>>>>>>>>>>>>>>>>>> implemented an alternative version that uses UDP sockets directly. It is currently called
>>>>>>>>>>>>>>>>>>>>>>> OSCsend2 and the interface is exactly the same to OSCsend. In our tests, it appears to
>>>>>>>>>>>>>>>>>>>>>>> do the job, but have not tested it extensively.
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> It has been suggested to remove OSCsend and replace it with OSCsend2, so I would
>>>>>>>>>>>>>>>>>>>>>>> like to check if OSCsend users could test OSCsend2 and let us know if there are differences
>>>>>>>>>>>>>>>>>>>>>>> and whether it works OK for you. We would also then like to know whether having
>>>>>>>>>>>>>>>>>>>>>>> OSCsend2 alongside OSCsend is your preference, or whether we should just replace it.
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>> Csound mailing list
>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>  https://github.com/csound/csound/issues
>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>> Csound mailing list
>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>> Send bugs reports to
>>>>>>>>>>  https://github.com/csound/csound/issues
>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>> Csound mailing list
>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>> Send bugs reports to
>>>>>>>>>   https://github.com/csound/csound/issues
>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>> Csound mailing list
>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>> Send bugs reports to
>>>>>>>>   https://github.com/csound/csound/issues
>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>> Csound mailing list
>>>>>>> Csound@listserv.heanet.ie
>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>> Send bugs reports to
>>>>>>>    https://github.com/csound/csound/issues
>>>>>>> Discussions of bugs and features can be posted here
>>>>>> Csound mailing list
>>>>>> Csound@listserv.heanet.ie
>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>> Send bugs reports to
>>>>>>     https://github.com/csound/csound/issues
>>>>>> Discussions of bugs and features can be posted here
>>>>> Csound mailing list
>>>>> Csound@listserv.heanet.ie
>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>> Send bugs reports to
>>>>>     https://github.com/csound/csound/issues
>>>>> Discussions of bugs and features can be posted here
>>>> Csound mailing list
>>>> Csound@listserv.heanet.ie
>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>> Send bugs reports to
>>>>      https://github.com/csound/csound/issues
>>>> Discussions of bugs and features can be posted here
>>> 
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>       https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>> 
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>        https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
> 
> 
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
> 
> 

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Here’s the code. Instrument 1 has a 4-element array and sends it over OSC to instrument 2.
This one has a 2-dim array with 2 rows 1 column (2 elements). When the array is received,
the columns grow to accommodate 2 extra numbers, turning this into a 2 x 2 matrix.

Note that if I don’t protect the printf call with an if …then, the first time the instrument
is run wil give the index out of range message, because the message hasn’t been
received yet. Once it is, the array grows. The rows never grow, only the columns (by design,
since we have to choose one or the other).

giosc OSCinit 7770

instr	1
kwhen  init 0
kmetro metro 1
kwhen += kmetro
kArr[] init 4
kArr[0] = kwhen
kArr[1] = kwhen+1
kArr[2] = kwhen+2
kArr[3] = kwhen+3
OSCsend2 kwhen, "127.0.0.1",7770, "/foo/bar", "D",kArr
endin

instr 2
ktrig init 1
kArr[][] init 2,1
top:
ka OSClisten giosc, "/foo/bar","D", kArr
if ka > 0 then
printf "%d %d \n%d %d\n", ka*ktrig,
     kArr[0][0], kArr[0][1], 
     kArr[1][0], kArr[1][1]
ktrig += 1     
endif
if ka > 0 kgoto top
endin
schedule(2,0,10)
schedule(1,0,10)


========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 7 Apr 2017, at 19:40, Victor Lazzarini  wrote:
> 
> I tested here with a 2d array, with size 1 on each dimension, then passed an array with 4  numbers over OSC and dim 1 (number of columns) grew to accommodate it. I am away from the computer but when I have the chance I will post a test CSD.
> 
> Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy
> Maynooth University
> Ireland
> 
>> On 7 Apr 2017, at 19:27, Guillermo Senna  wrote:
>> 
>> I'm getting the same thing, Victor.  Could you try the test files I'm
>> using? Maybe I'm expecting something that's not even possible.
>> 
>> 
>>> On 07/04/17 05:00, Victor Lazzarini wrote:
>>> I mean, not the higher ones!
>>> ========================
>>> Prof. Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy,
>>> Maynooth University,
>>> Maynooth, Co Kildare, Ireland
>>> Tel: 00 353 7086936
>>> Fax: 00 353 1 7086952 
>>> 
>>>> On 7 Apr 2017, at 08:58, Victor Lazzarini  wrote:
>>>> 
>>>> Ok, I had things back to front. Now it should work as I planned. The first dimension of the array changes,
>>>> not the lower ones. By first dimension I mean the columns in a row-column, ie. counting in the order in which the
>>>> indexes appear from right to left.
>>>> ========================
>>>> Prof. Victor Lazzarini
>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>> Maynooth University,
>>>> Maynooth, Co Kildare, Ireland
>>>> Tel: 00 353 7086936
>>>> Fax: 00 353 1 7086952 
>>>> 
>>>>> On 7 Apr 2017, at 08:02, Victor Lazzarini  wrote:
>>>>> 
>>>>> yes, I think I am mixing up dimension sizes, I will look. In any case, I will only be able to make one of the dimensions grow (as I can't guess how the matrix/cube/etc grows), whilst keeping the others fixed.
>>>>> 
>>>>> Victor Lazzarini
>>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>>> Maynooth University
>>>>> Ireland
>>>>> 
>>>>>> On 7 Apr 2017, at 07:40, Guillermo Senna  wrote:
>>>>>> 
>>>>>> If I send a unidimensional array (from inside or outside Csound) it does
>>>>>> grow organically!
>>>>>> 
>>>>>> 
>>>>>>> On 07/04/17 02:39, Victor Lazzarini wrote:
>>>>>>> It should be fixed now. The array was growing but I forgot to update the sizes.
>>>>>>> ========================
>>>>>>> Prof. Victor Lazzarini
>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>> Maynooth University,
>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>> Tel: 00 353 7086936
>>>>>>> Fax: 00 353 1 7086952 
>>>>>>> 
>>>>>>>> On 7 Apr 2017, at 06:16, Victor Lazzarini  wrote:
>>>>>>>> 
>>>>>>>> That shouldn't happen, the array should grow. I'll have a look and fix it.
>>>>>>>> 
>>>>>>>> Victor Lazzarini
>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>>>>>> Maynooth University
>>>>>>>> Ireland
>>>>>>>> 
>>>>>>>>> On 7 Apr 2017, at 04:30, Guillermo Senna  wrote:
>>>>>>>>> 
>>>>>>>>> I tested the new specifier from outside Csound. Now I understand what
>>>>>>>>> you mean Victor. The good thing is that it forces you to choose a common
>>>>>>>>> size between sender and receiver in advance and that prevents you from
>>>>>>>>> getting "osc::OutOfBufferMemoryException" while sending exceedingly
>>>>>>>>> large vectors. The bad thing is the need to process the received array
>>>>>>>>> and look for a delimiter while sending variable-sized arrays like I'm
>>>>>>>>> doing. Or maybe I can just send the size before through "/kArrSize" or
>>>>>>>>> something like that.
>>>>>>>>> 
>>>>>>>>> Just for the record, with the "A" specifier you can do "kArr[] init 1"
>>>>>>>>> and the array will still grow and shrink dynamically according to
>>>>>>>>> dimensions/sizes received. That is very convenient. With the "D"
>>>>>>>>> specifier you get "Array index 2 out of range (0,0) for dimension 1".
>>>>>>>>> 
>>>>>>>>> I've to think now how to effectively process the received the array, but
>>>>>>>>> I think you saved me from a difficult-to-diagnose bug that I'd probably
>>>>>>>>> have encountered in the future because of the UDP protocol.
>>>>>>>>> 
>>>>>>>>> I'll test OSCsend2 now. Cheers.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> On 06/04/17 18:33, Victor Lazzarini wrote:
>>>>>>>>>> Say you send 10 elements.
>>>>>>>>>> 
>>>>>>>>>> You can interpret this as
>>>>>>>>>> 
>>>>>>>>>> [1,2,3,4,5,6,7,8,9,10]
>>>>>>>>>> 
>>>>>>>>>> or
>>>>>>>>>> 
>>>>>>>>>> [1,2]
>>>>>>>>>> [3,4]
>>>>>>>>>> [5,6]
>>>>>>>>>> [7,8]
>>>>>>>>>> 
>>>>>>>>>> or
>>>>>>>>>> 
>>>>>>>>>> [1,2,3,4,5]
>>>>>>>>>> [6,7,8,9,10]
>>>>>>>>>> 
>>>>>>>>>> or
>>>>>>>>>> 
>>>>>>>>>> [1,2,3]
>>>>>>>>>> [4,5,6]
>>>>>>>>>> [7,8,9]
>>>>>>>>>> [10,0,0]
>>>>>>>>>> 
>>>>>>>>>> etc
>>>>>>>>>> 
>>>>>>>>>> Whatever you do, if there isn’t enough size, the array grows dynamically. In the last
>>>>>>>>>> example there was more than enough size, but we only copied  the 10 numbers
>>>>>>>>>> we got.
>>>>>>>>>> 
>>>>>>>>>> I have added this type to OSClisten  and OSCsend2. 
>>>>>>>>>> 
>>>>>>>>>> ========================
>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>> Maynooth University,
>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>> 
>>>>>>>>>>> On 6 Apr 2017, at 22:20, Guillermo Senna  wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Oh, I see. And in the 2D version, if I send a single blob/array with:
>>>>>>>>>>> 
>>>>>>>>>>> 10 elements -> they all end up in dimension no. 1
>>>>>>>>>>> 
>>>>>>>>>>> 30 elements -> they'd go 16-14
>>>>>>>>>>> 
>>>>>>>>>>> 40 elements -> 16-24
>>>>>>>>>>> 
>>>>>>>>>>> Or is it going to be an error not to match the dimensions/sizes?
>>>>>>>>>>> 
>>>>>>>>>>>> On 06/04/17 18:10, Victor Lazzarini wrote:
>>>>>>>>>>>> No, I mean
>>>>>>>>>>>> 
>>>>>>>>>>>> kArr[][] init 2, 16
>>>>>>>>>>>> kk1  OSClisten gihandle, "/multiArr", "D", kArr
>>>>>>>>>>>> 
>>>>>>>>>>>> or
>>>>>>>>>>>> 
>>>>>>>>>>>> kArr[] init 32
>>>>>>>>>>>> kk1  OSClisten gihandle, "/multiArr", "D", kArr
>>>>>>>>>>>> 
>>>>>>>>>>>> both working, the choice is yours
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> ========================
>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>> 
>>>>>>>>>>>>> On 6 Apr 2017, at 21:46, Guillermo Senna  wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I'm not so sure I follow you with that last sentence. Do you mean
>>>>>>>>>>>>> something like this could be possible?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> kArr[][] init 2, 16
>>>>>>>>>>>>> kk1  OSClisten gihandle, "/multiArr", "DD", kArr[0], kArr[1]
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On 06/04/17 17:36, Victor Lazzarini wrote:
>>>>>>>>>>>>>> yes, same thing from the user perspective. Except that you can define how many dimensions you want
>>>>>>>>>>>>>> to hold the data in.
>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On 6 Apr 2017, at 21:33, Guillermo Senna  wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I like that. Non of those characters are really part of the OSC
>>>>>>>>>>>>>>> specification, so why not?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> But with this approach you would still use a Csound array as xdata1 in
>>>>>>>>>>>>>>> OSClisten, right?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On 06/04/17 17:16, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>> We could put in a different type name for non-descript double-format data sequence (e.g. 2), for instance
>>>>>>>>>>>>>>>> call it “D”.
>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On 6 Apr 2017, at 21:04, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> I've not considered number 2 before. How about adding an opcode later
>>>>>>>>>>>>>>>>> for joining 2d arrays into a single multidimensional? Would it be to
>>>>>>>>>>>>>>>>> difficult/inefficient to do that considering that in the end it's all
>>>>>>>>>>>>>>>>> about pointers?
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> I don't want to change and break it for others already using the current
>>>>>>>>>>>>>>>>> structure.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On 05/04/17 18:12, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>> I see what you mean. It’s possible to change it, there are two options:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 1) encode everything with doubles
>>>>>>>>>>>>>>>>>> 2) leave dim and size. The size of the blob is always there before the
>>>>>>>>>>>>>>>>>> data, so we can just use that. It will be then up to the user to interpret
>>>>>>>>>>>>>>>>>> the data as a 1,2,3 ,… dimensional array. The data is always stored
>>>>>>>>>>>>>>>>>> as a flat vector (e.g. row-column for 2-d).
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> if people want it changed, I can do it.
>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> On 5 Apr 2017, at 18:24, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> My reasoning is that in the different programming languages you'd use a
>>>>>>>>>>>>>>>>>>> library/module for handling the OSC part and that would in turn have
>>>>>>>>>>>>>>>>>>> some abstraction for sending entire arrays as blobs. Now, Csound
>>>>>>>>>>>>>>>>>>> requests for two 32-bit ints and then the rest 64-bits doubles. Is that
>>>>>>>>>>>>>>>>>>> always possible to control in the higher-level languages?
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Initially what I'd have thought is that I could build an array with all
>>>>>>>>>>>>>>>>>>> doubles and Csound would internally truncate the first two values and
>>>>>>>>>>>>>>>>>>> cast them into ints.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> But if it's working for everyone right now nothing should be changed!
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> On 05/04/17 14:04, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>>>> Well, Csound reads two ints, as far as I can see. So I would expect that you can just send two
>>>>>>>>>>>>>>>>>>>> separate ints and Csound would understand it (first the dimension, then the size). This is
>>>>>>>>>>>>>>>>>>>> what OSCsend2 (& OSCsend) does. Not quite sure what might be going on at your end.
>>>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> On 5 Apr 2017, at 17:44, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> Well I'm doing it in C++ with oscpack and for me it works. Now, I don't
>>>>>>>>>>>>>>>>>>>>> know much about python for example, but if you are using a python module
>>>>>>>>>>>>>>>>>>>>> for handling the OSC part of your program, is it possible to construct
>>>>>>>>>>>>>>>>>>>>> the array to be sent as two ints and the rest as doubles?
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> I'm asking from complete ignorance, Victor. It just seemed odd to
>>>>>>>>>>>>>>>>>>>>> (instead of passing my entire vector in C++) have to do something like this:
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> unsigned long ui = qvlist.size();
>>>>>>>>>>>>>>>>>>>>> ui <<= 32; ui |= 1;
>>>>>>>>>>>>>>>>>>>>> vec.push_back (*(double*)&ui);
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> On 05/04/17 13:30, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>>>>>> I have implemented the array, audio and function table as per OSCsend/OSClisten. As far as I can see from the code, the blob is as you
>>>>>>>>>>>>>>>>>>>>>> describe, all data being sent in the native endianess (little endian for i386/x86_64). It could be that the OSC lib is expecting the data
>>>>>>>>>>>>>>>>>>>>>> in big-endian ints, 4 bytes at a time. As far as I understand, the OSC should not impose any particular interpretation to the blob,
>>>>>>>>>>>>>>>>>>>>>> but just take it as a string of bytes.
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> On 5 Apr 2017, at 17:03, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> I'll try it in a few moments. Are you going to replace OSClisten too? If
>>>>>>>>>>>>>>>>>>>>>>> you do, please beware that right now receiving an array in Csound
>>>>>>>>>>>>>>>>>>>>>>> expects the structure [dimensions(int); size(int); values(double)...]. I
>>>>>>>>>>>>>>>>>>>>>>> had to bitshift and cast two ints as a double in order to make that work
>>>>>>>>>>>>>>>>>>>>>>> from a third-party OSC library outside Csound. It didn't seem right and
>>>>>>>>>>>>>>>>>>>>>>> I don't think it's possible in every programming language.
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> Cheers.
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> On 05/04/17 08:30, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>>>>>>>> Following our conclusion that liblo seems to be overly heavy weight for OSC sending, I have
>>>>>>>>>>>>>>>>>>>>>>>> implemented an alternative version that uses UDP sockets directly. It is currently called
>>>>>>>>>>>>>>>>>>>>>>>> OSCsend2 and the interface is exactly the same to OSCsend. In our tests, it appears to
>>>>>>>>>>>>>>>>>>>>>>>> do the job, but have not tested it extensively.
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> It has been suggested to remove OSCsend and replace it with OSCsend2, so I would
>>>>>>>>>>>>>>>>>>>>>>>> like to check if OSCsend users could test OSCsend2 and let us know if there are differences
>>>>>>>>>>>>>>>>>>>>>>>> and whether it works OK for you. We would also then like to know whether having
>>>>>>>>>>>>>>>>>>>>>>>> OSCsend2 alongside OSCsend is your preference, or whether we should just replace it.
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>> Csound mailing list
>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>> Csound mailing list
>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>> Send bugs reports to
>>>>>>>>>>  https://github.com/csound/csound/issues
>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>> Csound mailing list
>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>> Send bugs reports to
>>>>>>>>>  https://github.com/csound/csound/issues
>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>> Csound mailing list
>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>> Send bugs reports to
>>>>>>>>   https://github.com/csound/csound/issues
>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>> Csound mailing list
>>>>>>> Csound@listserv.heanet.ie
>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>> Send bugs reports to
>>>>>>>    https://github.com/csound/csound/issues
>>>>>>> Discussions of bugs and features can be posted here
>>>>>> Csound mailing list
>>>>>> Csound@listserv.heanet.ie
>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>> Send bugs reports to
>>>>>>    https://github.com/csound/csound/issues
>>>>>> Discussions of bugs and features can be posted here
>>>>> Csound mailing list
>>>>> Csound@listserv.heanet.ie
>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>> Send bugs reports to
>>>>>     https://github.com/csound/csound/issues
>>>>> Discussions of bugs and features can be posted here
>>>> 
>>>> Csound mailing list
>>>> Csound@listserv.heanet.ie
>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>> Send bugs reports to
>>>>      https://github.com/csound/csound/issues
>>>> Discussions of bugs and features can be posted here
>>> 
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>       https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>> 
>> 
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>       https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>> 
>> 
> 
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here


Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Yes, this one works fine. Although I tried growing the sending array
(1D) to 8 elements and at the receiving end the following sentence still
equals 4.

lenarray:i(kArr, 0) * lenarray:i(kArr)

Then I tried sending a 2D array (2 rows; 4 columns) but that doesn't
work as it doesn't receive [0][3] and [1][3]. I mean it's fine with me
as I don't need that feature. But maybe there should be a warning in the
future new man page.


On 07/04/17 16:57, Victor Lazzarini wrote:
> Here’s the code. Instrument 1 has a 4-element array and sends it over OSC to instrument 2.
> This one has a 2-dim array with 2 rows 1 column (2 elements). When the array is received,
> the columns grow to accommodate 2 extra numbers, turning this into a 2 x 2 matrix.
>
> Note that if I don’t protect the printf call with an if …then, the first time the instrument
> is run wil give the index out of range message, because the message hasn’t been
> received yet. Once it is, the array grows. The rows never grow, only the columns (by design,
> since we have to choose one or the other).
>
> giosc OSCinit 7770
>
> instr	1
> kwhen  init 0
> kmetro metro 1
> kwhen += kmetro
> kArr[] init 4
> kArr[0] = kwhen
> kArr[1] = kwhen+1
> kArr[2] = kwhen+2
> kArr[3] = kwhen+3
> OSCsend2 kwhen, "127.0.0.1",7770, "/foo/bar", "D",kArr
> endin
>
> instr 2
> ktrig init 1
> kArr[][] init 2,1
> top:
> ka OSClisten giosc, "/foo/bar","D", kArr
> if ka > 0 then
> printf "%d %d \n%d %d\n", ka*ktrig,
>      kArr[0][0], kArr[0][1], 
>      kArr[1][0], kArr[1][1]
> ktrig += 1     
> endif
> if ka > 0 kgoto top
> endin
> schedule(2,0,10)
> schedule(1,0,10)
>
>
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952 
>
>> On 7 Apr 2017, at 19:40, Victor Lazzarini  wrote:
>>
>> I tested here with a 2d array, with size 1 on each dimension, then passed an array with 4  numbers over OSC and dim 1 (number of columns) grew to accommodate it. I am away from the computer but when I have the chance I will post a test CSD.
>>
>> Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy
>> Maynooth University
>> Ireland
>>
>>> On 7 Apr 2017, at 19:27, Guillermo Senna  wrote:
>>>
>>> I'm getting the same thing, Victor.  Could you try the test files I'm
>>> using? Maybe I'm expecting something that's not even possible.
>>>
>>>
>>>> On 07/04/17 05:00, Victor Lazzarini wrote:
>>>> I mean, not the higher ones!
>>>> ========================
>>>> Prof. Victor Lazzarini
>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>> Maynooth University,
>>>> Maynooth, Co Kildare, Ireland
>>>> Tel: 00 353 7086936
>>>> Fax: 00 353 1 7086952 
>>>>
>>>>> On 7 Apr 2017, at 08:58, Victor Lazzarini  wrote:
>>>>>
>>>>> Ok, I had things back to front. Now it should work as I planned. The first dimension of the array changes,
>>>>> not the lower ones. By first dimension I mean the columns in a row-column, ie. counting in the order in which the
>>>>> indexes appear from right to left.
>>>>> ========================
>>>>> Prof. Victor Lazzarini
>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>> Maynooth University,
>>>>> Maynooth, Co Kildare, Ireland
>>>>> Tel: 00 353 7086936
>>>>> Fax: 00 353 1 7086952 
>>>>>
>>>>>> On 7 Apr 2017, at 08:02, Victor Lazzarini  wrote:
>>>>>>
>>>>>> yes, I think I am mixing up dimension sizes, I will look. In any case, I will only be able to make one of the dimensions grow (as I can't guess how the matrix/cube/etc grows), whilst keeping the others fixed.
>>>>>>
>>>>>> Victor Lazzarini
>>>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>>>> Maynooth University
>>>>>> Ireland
>>>>>>
>>>>>>> On 7 Apr 2017, at 07:40, Guillermo Senna  wrote:
>>>>>>>
>>>>>>> If I send a unidimensional array (from inside or outside Csound) it does
>>>>>>> grow organically!
>>>>>>>
>>>>>>>
>>>>>>>> On 07/04/17 02:39, Victor Lazzarini wrote:
>>>>>>>> It should be fixed now. The array was growing but I forgot to update the sizes.
>>>>>>>> ========================
>>>>>>>> Prof. Victor Lazzarini
>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>> Maynooth University,
>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>> Tel: 00 353 7086936
>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>
>>>>>>>>> On 7 Apr 2017, at 06:16, Victor Lazzarini  wrote:
>>>>>>>>>
>>>>>>>>> That shouldn't happen, the array should grow. I'll have a look and fix it.
>>>>>>>>>
>>>>>>>>> Victor Lazzarini
>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>>>>>>> Maynooth University
>>>>>>>>> Ireland
>>>>>>>>>
>>>>>>>>>> On 7 Apr 2017, at 04:30, Guillermo Senna  wrote:
>>>>>>>>>>
>>>>>>>>>> I tested the new specifier from outside Csound. Now I understand what
>>>>>>>>>> you mean Victor. The good thing is that it forces you to choose a common
>>>>>>>>>> size between sender and receiver in advance and that prevents you from
>>>>>>>>>> getting "osc::OutOfBufferMemoryException" while sending exceedingly
>>>>>>>>>> large vectors. The bad thing is the need to process the received array
>>>>>>>>>> and look for a delimiter while sending variable-sized arrays like I'm
>>>>>>>>>> doing. Or maybe I can just send the size before through "/kArrSize" or
>>>>>>>>>> something like that.
>>>>>>>>>>
>>>>>>>>>> Just for the record, with the "A" specifier you can do "kArr[] init 1"
>>>>>>>>>> and the array will still grow and shrink dynamically according to
>>>>>>>>>> dimensions/sizes received. That is very convenient. With the "D"
>>>>>>>>>> specifier you get "Array index 2 out of range (0,0) for dimension 1".
>>>>>>>>>>
>>>>>>>>>> I've to think now how to effectively process the received the array, but
>>>>>>>>>> I think you saved me from a difficult-to-diagnose bug that I'd probably
>>>>>>>>>> have encountered in the future because of the UDP protocol.
>>>>>>>>>>
>>>>>>>>>> I'll test OSCsend2 now. Cheers.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On 06/04/17 18:33, Victor Lazzarini wrote:
>>>>>>>>>>> Say you send 10 elements.
>>>>>>>>>>>
>>>>>>>>>>> You can interpret this as
>>>>>>>>>>>
>>>>>>>>>>> [1,2,3,4,5,6,7,8,9,10]
>>>>>>>>>>>
>>>>>>>>>>> or
>>>>>>>>>>>
>>>>>>>>>>> [1,2]
>>>>>>>>>>> [3,4]
>>>>>>>>>>> [5,6]
>>>>>>>>>>> [7,8]
>>>>>>>>>>>
>>>>>>>>>>> or
>>>>>>>>>>>
>>>>>>>>>>> [1,2,3,4,5]
>>>>>>>>>>> [6,7,8,9,10]
>>>>>>>>>>>
>>>>>>>>>>> or
>>>>>>>>>>>
>>>>>>>>>>> [1,2,3]
>>>>>>>>>>> [4,5,6]
>>>>>>>>>>> [7,8,9]
>>>>>>>>>>> [10,0,0]
>>>>>>>>>>>
>>>>>>>>>>> etc
>>>>>>>>>>>
>>>>>>>>>>> Whatever you do, if there isn’t enough size, the array grows dynamically. In the last
>>>>>>>>>>> example there was more than enough size, but we only copied  the 10 numbers
>>>>>>>>>>> we got.
>>>>>>>>>>>
>>>>>>>>>>> I have added this type to OSClisten  and OSCsend2. 
>>>>>>>>>>>
>>>>>>>>>>> ========================
>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>> Maynooth University,
>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>
>>>>>>>>>>>> On 6 Apr 2017, at 22:20, Guillermo Senna  wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Oh, I see. And in the 2D version, if I send a single blob/array with:
>>>>>>>>>>>>
>>>>>>>>>>>> 10 elements -> they all end up in dimension no. 1
>>>>>>>>>>>>
>>>>>>>>>>>> 30 elements -> they'd go 16-14
>>>>>>>>>>>>
>>>>>>>>>>>> 40 elements -> 16-24
>>>>>>>>>>>>
>>>>>>>>>>>> Or is it going to be an error not to match the dimensions/sizes?
>>>>>>>>>>>>
>>>>>>>>>>>>> On 06/04/17 18:10, Victor Lazzarini wrote:
>>>>>>>>>>>>> No, I mean
>>>>>>>>>>>>>
>>>>>>>>>>>>> kArr[][] init 2, 16
>>>>>>>>>>>>> kk1  OSClisten gihandle, "/multiArr", "D", kArr
>>>>>>>>>>>>>
>>>>>>>>>>>>> or
>>>>>>>>>>>>>
>>>>>>>>>>>>> kArr[] init 32
>>>>>>>>>>>>> kk1  OSClisten gihandle, "/multiArr", "D", kArr
>>>>>>>>>>>>>
>>>>>>>>>>>>> both working, the choice is yours
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ========================
>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 6 Apr 2017, at 21:46, Guillermo Senna  wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm not so sure I follow you with that last sentence. Do you mean
>>>>>>>>>>>>>> something like this could be possible?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> kArr[][] init 2, 16
>>>>>>>>>>>>>> kk1  OSClisten gihandle, "/multiArr", "DD", kArr[0], kArr[1]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 06/04/17 17:36, Victor Lazzarini wrote:
>>>>>>>>>>>>>>> yes, same thing from the user perspective. Except that you can define how many dimensions you want
>>>>>>>>>>>>>>> to hold the data in.
>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 6 Apr 2017, at 21:33, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I like that. Non of those characters are really part of the OSC
>>>>>>>>>>>>>>>> specification, so why not?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> But with this approach you would still use a Csound array as xdata1 in
>>>>>>>>>>>>>>>> OSClisten, right?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 06/04/17 17:16, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>> We could put in a different type name for non-descript double-format data sequence (e.g. 2), for instance
>>>>>>>>>>>>>>>>> call it “D”.
>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 6 Apr 2017, at 21:04, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I've not considered number 2 before. How about adding an opcode later
>>>>>>>>>>>>>>>>>> for joining 2d arrays into a single multidimensional? Would it be to
>>>>>>>>>>>>>>>>>> difficult/inefficient to do that considering that in the end it's all
>>>>>>>>>>>>>>>>>> about pointers?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I don't want to change and break it for others already using the current
>>>>>>>>>>>>>>>>>> structure.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 05/04/17 18:12, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>>> I see what you mean. It’s possible to change it, there are two options:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 1) encode everything with doubles
>>>>>>>>>>>>>>>>>>> 2) leave dim and size. The size of the blob is always there before the
>>>>>>>>>>>>>>>>>>> data, so we can just use that. It will be then up to the user to interpret
>>>>>>>>>>>>>>>>>>> the data as a 1,2,3 ,… dimensional array. The data is always stored
>>>>>>>>>>>>>>>>>>> as a flat vector (e.g. row-column for 2-d).
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> if people want it changed, I can do it.
>>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 5 Apr 2017, at 18:24, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> My reasoning is that in the different programming languages you'd use a
>>>>>>>>>>>>>>>>>>>> library/module for handling the OSC part and that would in turn have
>>>>>>>>>>>>>>>>>>>> some abstraction for sending entire arrays as blobs. Now, Csound
>>>>>>>>>>>>>>>>>>>> requests for two 32-bit ints and then the rest 64-bits doubles. Is that
>>>>>>>>>>>>>>>>>>>> always possible to control in the higher-level languages?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Initially what I'd have thought is that I could build an array with all
>>>>>>>>>>>>>>>>>>>> doubles and Csound would internally truncate the first two values and
>>>>>>>>>>>>>>>>>>>> cast them into ints.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> But if it's working for everyone right now nothing should be changed!
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 05/04/17 14:04, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>>>>> Well, Csound reads two ints, as far as I can see. So I would expect that you can just send two
>>>>>>>>>>>>>>>>>>>>> separate ints and Csound would understand it (first the dimension, then the size). This is
>>>>>>>>>>>>>>>>>>>>> what OSCsend2 (& OSCsend) does. Not quite sure what might be going on at your end.
>>>>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 5 Apr 2017, at 17:44, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Well I'm doing it in C++ with oscpack and for me it works. Now, I don't
>>>>>>>>>>>>>>>>>>>>>> know much about python for example, but if you are using a python module
>>>>>>>>>>>>>>>>>>>>>> for handling the OSC part of your program, is it possible to construct
>>>>>>>>>>>>>>>>>>>>>> the array to be sent as two ints and the rest as doubles?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I'm asking from complete ignorance, Victor. It just seemed odd to
>>>>>>>>>>>>>>>>>>>>>> (instead of passing my entire vector in C++) have to do something like this:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> unsigned long ui = qvlist.size();
>>>>>>>>>>>>>>>>>>>>>> ui <<= 32; ui |= 1;
>>>>>>>>>>>>>>>>>>>>>> vec.push_back (*(double*)&ui);
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 05/04/17 13:30, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>>>>>>> I have implemented the array, audio and function table as per OSCsend/OSClisten. As far as I can see from the code, the blob is as you
>>>>>>>>>>>>>>>>>>>>>>> describe, all data being sent in the native endianess (little endian for i386/x86_64). It could be that the OSC lib is expecting the data
>>>>>>>>>>>>>>>>>>>>>>> in big-endian ints, 4 bytes at a time. As far as I understand, the OSC should not impose any particular interpretation to the blob,
>>>>>>>>>>>>>>>>>>>>>>> but just take it as a string of bytes.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On 5 Apr 2017, at 17:03, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I'll try it in a few moments. Are you going to replace OSClisten too? If
>>>>>>>>>>>>>>>>>>>>>>>> you do, please beware that right now receiving an array in Csound
>>>>>>>>>>>>>>>>>>>>>>>> expects the structure [dimensions(int); size(int); values(double)...]. I
>>>>>>>>>>>>>>>>>>>>>>>> had to bitshift and cast two ints as a double in order to make that work
>>>>>>>>>>>>>>>>>>>>>>>> from a third-party OSC library outside Csound. It didn't seem right and
>>>>>>>>>>>>>>>>>>>>>>>> I don't think it's possible in every programming language.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Cheers.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On 05/04/17 08:30, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> Following our conclusion that liblo seems to be overly heavy weight for OSC sending, I have
>>>>>>>>>>>>>>>>>>>>>>>>> implemented an alternative version that uses UDP sockets directly. It is currently called
>>>>>>>>>>>>>>>>>>>>>>>>> OSCsend2 and the interface is exactly the same to OSCsend. In our tests, it appears to
>>>>>>>>>>>>>>>>>>>>>>>>> do the job, but have not tested it extensively.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> It has been suggested to remove OSCsend and replace it with OSCsend2, so I would
>>>>>>>>>>>>>>>>>>>>>>>>> like to check if OSCsend users could test OSCsend2 and let us know if there are differences
>>>>>>>>>>>>>>>>>>>>>>>>> and whether it works OK for you. We would also then like to know whether having
>>>>>>>>>>>>>>>>>>>>>>>>> OSCsend2 alongside OSCsend is your preference, or whether we should just replace it.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>> Csound mailing list
>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>  https://github.com/csound/csound/issues
>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>> Csound mailing list
>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>> Send bugs reports to
>>>>>>>>>>  https://github.com/csound/csound/issues
>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>> Csound mailing list
>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>> Send bugs reports to
>>>>>>>>>   https://github.com/csound/csound/issues
>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>> Csound mailing list
>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>> Send bugs reports to
>>>>>>>>    https://github.com/csound/csound/issues
>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>> Csound mailing list
>>>>>>> Csound@listserv.heanet.ie
>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>> Send bugs reports to
>>>>>>>    https://github.com/csound/csound/issues
>>>>>>> Discussions of bugs and features can be posted here
>>>>>> Csound mailing list
>>>>>> Csound@listserv.heanet.ie
>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>> Send bugs reports to
>>>>>>     https://github.com/csound/csound/issues
>>>>>> Discussions of bugs and features can be posted here
>>>>> Csound mailing list
>>>>> Csound@listserv.heanet.ie
>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>> Send bugs reports to
>>>>>      https://github.com/csound/csound/issues
>>>>> Discussions of bugs and features can be posted here
>>>> Csound mailing list
>>>> Csound@listserv.heanet.ie
>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>> Send bugs reports to
>>>>       https://github.com/csound/csound/issues
>>>> Discussions of bugs and features can be posted here
>>>
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>       https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>>> 
>>> 
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>        https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I think it might be something to do with lenarray rather than this opcode. Try to
access the extra members and you will see that they are there.
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 7 Apr 2017, at 21:24, Guillermo Senna  wrote:
> 
> Yes, this one works fine. Although I tried growing the sending array
> (1D) to 8 elements and at the receiving end the following sentence still
> equals 4.
> 
> lenarray:i(kArr, 0) * lenarray:i(kArr)
> 
> Then I tried sending a 2D array (2 rows; 4 columns) but that doesn't
> work as it doesn't receive [0][3] and [1][3]. I mean it's fine with me
> as I don't need that feature. But maybe there should be a warning in the
> future new man page.
> 
> 
> On 07/04/17 16:57, Victor Lazzarini wrote:
>> Here’s the code. Instrument 1 has a 4-element array and sends it over OSC to instrument 2.
>> This one has a 2-dim array with 2 rows 1 column (2 elements). When the array is received,
>> the columns grow to accommodate 2 extra numbers, turning this into a 2 x 2 matrix.
>> 
>> Note that if I don’t protect the printf call with an if …then, the first time the instrument
>> is run wil give the index out of range message, because the message hasn’t been
>> received yet. Once it is, the array grows. The rows never grow, only the columns (by design,
>> since we have to choose one or the other).
>> 
>> giosc OSCinit 7770
>> 
>> instr	1
>> kwhen  init 0
>> kmetro metro 1
>> kwhen += kmetro
>> kArr[] init 4
>> kArr[0] = kwhen
>> kArr[1] = kwhen+1
>> kArr[2] = kwhen+2
>> kArr[3] = kwhen+3
>> OSCsend2 kwhen, "127.0.0.1",7770, "/foo/bar", "D",kArr
>> endin
>> 
>> instr 2
>> ktrig init 1
>> kArr[][] init 2,1
>> top:
>> ka OSClisten giosc, "/foo/bar","D", kArr
>> if ka > 0 then
>> printf "%d %d \n%d %d\n", ka*ktrig,
>>     kArr[0][0], kArr[0][1], 
>>     kArr[1][0], kArr[1][1]
>> ktrig += 1     
>> endif
>> if ka > 0 kgoto top
>> endin
>> schedule(2,0,10)
>> schedule(1,0,10)
>> 
>> 
>> ========================
>> Prof. Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy,
>> Maynooth University,
>> Maynooth, Co Kildare, Ireland
>> Tel: 00 353 7086936
>> Fax: 00 353 1 7086952 
>> 
>>> On 7 Apr 2017, at 19:40, Victor Lazzarini  wrote:
>>> 
>>> I tested here with a 2d array, with size 1 on each dimension, then passed an array with 4  numbers over OSC and dim 1 (number of columns) grew to accommodate it. I am away from the computer but when I have the chance I will post a test CSD.
>>> 
>>> Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy
>>> Maynooth University
>>> Ireland
>>> 
>>>> On 7 Apr 2017, at 19:27, Guillermo Senna  wrote:
>>>> 
>>>> I'm getting the same thing, Victor.  Could you try the test files I'm
>>>> using? Maybe I'm expecting something that's not even possible.
>>>> 
>>>> 
>>>>> On 07/04/17 05:00, Victor Lazzarini wrote:
>>>>> I mean, not the higher ones!
>>>>> ========================
>>>>> Prof. Victor Lazzarini
>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>> Maynooth University,
>>>>> Maynooth, Co Kildare, Ireland
>>>>> Tel: 00 353 7086936
>>>>> Fax: 00 353 1 7086952 
>>>>> 
>>>>>> On 7 Apr 2017, at 08:58, Victor Lazzarini  wrote:
>>>>>> 
>>>>>> Ok, I had things back to front. Now it should work as I planned. The first dimension of the array changes,
>>>>>> not the lower ones. By first dimension I mean the columns in a row-column, ie. counting in the order in which the
>>>>>> indexes appear from right to left.
>>>>>> ========================
>>>>>> Prof. Victor Lazzarini
>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>> Maynooth University,
>>>>>> Maynooth, Co Kildare, Ireland
>>>>>> Tel: 00 353 7086936
>>>>>> Fax: 00 353 1 7086952 
>>>>>> 
>>>>>>> On 7 Apr 2017, at 08:02, Victor Lazzarini  wrote:
>>>>>>> 
>>>>>>> yes, I think I am mixing up dimension sizes, I will look. In any case, I will only be able to make one of the dimensions grow (as I can't guess how the matrix/cube/etc grows), whilst keeping the others fixed.
>>>>>>> 
>>>>>>> Victor Lazzarini
>>>>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>>>>> Maynooth University
>>>>>>> Ireland
>>>>>>> 
>>>>>>>> On 7 Apr 2017, at 07:40, Guillermo Senna  wrote:
>>>>>>>> 
>>>>>>>> If I send a unidimensional array (from inside or outside Csound) it does
>>>>>>>> grow organically!
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On 07/04/17 02:39, Victor Lazzarini wrote:
>>>>>>>>> It should be fixed now. The array was growing but I forgot to update the sizes.
>>>>>>>>> ========================
>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>> Maynooth University,
>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>> 
>>>>>>>>>> On 7 Apr 2017, at 06:16, Victor Lazzarini  wrote:
>>>>>>>>>> 
>>>>>>>>>> That shouldn't happen, the array should grow. I'll have a look and fix it.
>>>>>>>>>> 
>>>>>>>>>> Victor Lazzarini
>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>>>>>>>> Maynooth University
>>>>>>>>>> Ireland
>>>>>>>>>> 
>>>>>>>>>>> On 7 Apr 2017, at 04:30, Guillermo Senna  wrote:
>>>>>>>>>>> 
>>>>>>>>>>> I tested the new specifier from outside Csound. Now I understand what
>>>>>>>>>>> you mean Victor. The good thing is that it forces you to choose a common
>>>>>>>>>>> size between sender and receiver in advance and that prevents you from
>>>>>>>>>>> getting "osc::OutOfBufferMemoryException" while sending exceedingly
>>>>>>>>>>> large vectors. The bad thing is the need to process the received array
>>>>>>>>>>> and look for a delimiter while sending variable-sized arrays like I'm
>>>>>>>>>>> doing. Or maybe I can just send the size before through "/kArrSize" or
>>>>>>>>>>> something like that.
>>>>>>>>>>> 
>>>>>>>>>>> Just for the record, with the "A" specifier you can do "kArr[] init 1"
>>>>>>>>>>> and the array will still grow and shrink dynamically according to
>>>>>>>>>>> dimensions/sizes received. That is very convenient. With the "D"
>>>>>>>>>>> specifier you get "Array index 2 out of range (0,0) for dimension 1".
>>>>>>>>>>> 
>>>>>>>>>>> I've to think now how to effectively process the received the array, but
>>>>>>>>>>> I think you saved me from a difficult-to-diagnose bug that I'd probably
>>>>>>>>>>> have encountered in the future because of the UDP protocol.
>>>>>>>>>>> 
>>>>>>>>>>> I'll test OSCsend2 now. Cheers.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> On 06/04/17 18:33, Victor Lazzarini wrote:
>>>>>>>>>>>> Say you send 10 elements.
>>>>>>>>>>>> 
>>>>>>>>>>>> You can interpret this as
>>>>>>>>>>>> 
>>>>>>>>>>>> [1,2,3,4,5,6,7,8,9,10]
>>>>>>>>>>>> 
>>>>>>>>>>>> or
>>>>>>>>>>>> 
>>>>>>>>>>>> [1,2]
>>>>>>>>>>>> [3,4]
>>>>>>>>>>>> [5,6]
>>>>>>>>>>>> [7,8]
>>>>>>>>>>>> 
>>>>>>>>>>>> or
>>>>>>>>>>>> 
>>>>>>>>>>>> [1,2,3,4,5]
>>>>>>>>>>>> [6,7,8,9,10]
>>>>>>>>>>>> 
>>>>>>>>>>>> or
>>>>>>>>>>>> 
>>>>>>>>>>>> [1,2,3]
>>>>>>>>>>>> [4,5,6]
>>>>>>>>>>>> [7,8,9]
>>>>>>>>>>>> [10,0,0]
>>>>>>>>>>>> 
>>>>>>>>>>>> etc
>>>>>>>>>>>> 
>>>>>>>>>>>> Whatever you do, if there isn’t enough size, the array grows dynamically. In the last
>>>>>>>>>>>> example there was more than enough size, but we only copied  the 10 numbers
>>>>>>>>>>>> we got.
>>>>>>>>>>>> 
>>>>>>>>>>>> I have added this type to OSClisten  and OSCsend2. 
>>>>>>>>>>>> 
>>>>>>>>>>>> ========================
>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>> 
>>>>>>>>>>>>> On 6 Apr 2017, at 22:20, Guillermo Senna  wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Oh, I see. And in the 2D version, if I send a single blob/array with:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 10 elements -> they all end up in dimension no. 1
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 30 elements -> they'd go 16-14
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 40 elements -> 16-24
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Or is it going to be an error not to match the dimensions/sizes?
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On 06/04/17 18:10, Victor Lazzarini wrote:
>>>>>>>>>>>>>> No, I mean
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> kArr[][] init 2, 16
>>>>>>>>>>>>>> kk1  OSClisten gihandle, "/multiArr", "D", kArr
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> or
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> kArr[] init 32
>>>>>>>>>>>>>> kk1  OSClisten gihandle, "/multiArr", "D", kArr
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> both working, the choice is yours
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On 6 Apr 2017, at 21:46, Guillermo Senna  wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I'm not so sure I follow you with that last sentence. Do you mean
>>>>>>>>>>>>>>> something like this could be possible?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> kArr[][] init 2, 16
>>>>>>>>>>>>>>> kk1  OSClisten gihandle, "/multiArr", "DD", kArr[0], kArr[1]
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On 06/04/17 17:36, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>> yes, same thing from the user perspective. Except that you can define how many dimensions you want
>>>>>>>>>>>>>>>> to hold the data in.
>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On 6 Apr 2017, at 21:33, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> I like that. Non of those characters are really part of the OSC
>>>>>>>>>>>>>>>>> specification, so why not?
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> But with this approach you would still use a Csound array as xdata1 in
>>>>>>>>>>>>>>>>> OSClisten, right?
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On 06/04/17 17:16, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>> We could put in a different type name for non-descript double-format data sequence (e.g. 2), for instance
>>>>>>>>>>>>>>>>>> call it “D”.
>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> On 6 Apr 2017, at 21:04, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> I've not considered number 2 before. How about adding an opcode later
>>>>>>>>>>>>>>>>>>> for joining 2d arrays into a single multidimensional? Would it be to
>>>>>>>>>>>>>>>>>>> difficult/inefficient to do that considering that in the end it's all
>>>>>>>>>>>>>>>>>>> about pointers?
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> I don't want to change and break it for others already using the current
>>>>>>>>>>>>>>>>>>> structure.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> On 05/04/17 18:12, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>>>> I see what you mean. It’s possible to change it, there are two options:
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 1) encode everything with doubles
>>>>>>>>>>>>>>>>>>>> 2) leave dim and size. The size of the blob is always there before the
>>>>>>>>>>>>>>>>>>>> data, so we can just use that. It will be then up to the user to interpret
>>>>>>>>>>>>>>>>>>>> the data as a 1,2,3 ,… dimensional array. The data is always stored
>>>>>>>>>>>>>>>>>>>> as a flat vector (e.g. row-column for 2-d).
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> if people want it changed, I can do it.
>>>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> On 5 Apr 2017, at 18:24, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> My reasoning is that in the different programming languages you'd use a
>>>>>>>>>>>>>>>>>>>>> library/module for handling the OSC part and that would in turn have
>>>>>>>>>>>>>>>>>>>>> some abstraction for sending entire arrays as blobs. Now, Csound
>>>>>>>>>>>>>>>>>>>>> requests for two 32-bit ints and then the rest 64-bits doubles. Is that
>>>>>>>>>>>>>>>>>>>>> always possible to control in the higher-level languages?
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> Initially what I'd have thought is that I could build an array with all
>>>>>>>>>>>>>>>>>>>>> doubles and Csound would internally truncate the first two values and
>>>>>>>>>>>>>>>>>>>>> cast them into ints.
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> But if it's working for everyone right now nothing should be changed!
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> On 05/04/17 14:04, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>>>>>> Well, Csound reads two ints, as far as I can see. So I would expect that you can just send two
>>>>>>>>>>>>>>>>>>>>>> separate ints and Csound would understand it (first the dimension, then the size). This is
>>>>>>>>>>>>>>>>>>>>>> what OSCsend2 (& OSCsend) does. Not quite sure what might be going on at your end.
>>>>>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> On 5 Apr 2017, at 17:44, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> Well I'm doing it in C++ with oscpack and for me it works. Now, I don't
>>>>>>>>>>>>>>>>>>>>>>> know much about python for example, but if you are using a python module
>>>>>>>>>>>>>>>>>>>>>>> for handling the OSC part of your program, is it possible to construct
>>>>>>>>>>>>>>>>>>>>>>> the array to be sent as two ints and the rest as doubles?
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> I'm asking from complete ignorance, Victor. It just seemed odd to
>>>>>>>>>>>>>>>>>>>>>>> (instead of passing my entire vector in C++) have to do something like this:
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> unsigned long ui = qvlist.size();
>>>>>>>>>>>>>>>>>>>>>>> ui <<= 32; ui |= 1;
>>>>>>>>>>>>>>>>>>>>>>> vec.push_back (*(double*)&ui);
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> On 05/04/17 13:30, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>>>>>>>> I have implemented the array, audio and function table as per OSCsend/OSClisten. As far as I can see from the code, the blob is as you
>>>>>>>>>>>>>>>>>>>>>>>> describe, all data being sent in the native endianess (little endian for i386/x86_64). It could be that the OSC lib is expecting the data
>>>>>>>>>>>>>>>>>>>>>>>> in big-endian ints, 4 bytes at a time. As far as I understand, the OSC should not impose any particular interpretation to the blob,
>>>>>>>>>>>>>>>>>>>>>>>> but just take it as a string of bytes.
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> On 5 Apr 2017, at 17:03, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> I'll try it in a few moments. Are you going to replace OSClisten too? If
>>>>>>>>>>>>>>>>>>>>>>>>> you do, please beware that right now receiving an array in Csound
>>>>>>>>>>>>>>>>>>>>>>>>> expects the structure [dimensions(int); size(int); values(double)...]. I
>>>>>>>>>>>>>>>>>>>>>>>>> had to bitshift and cast two ints as a double in order to make that work
>>>>>>>>>>>>>>>>>>>>>>>>> from a third-party OSC library outside Csound. It didn't seem right and
>>>>>>>>>>>>>>>>>>>>>>>>> I don't think it's possible in every programming language.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Cheers.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> On 05/04/17 08:30, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> Following our conclusion that liblo seems to be overly heavy weight for OSC sending, I have
>>>>>>>>>>>>>>>>>>>>>>>>>> implemented an alternative version that uses UDP sockets directly. It is currently called
>>>>>>>>>>>>>>>>>>>>>>>>>> OSCsend2 and the interface is exactly the same to OSCsend. In our tests, it appears to
>>>>>>>>>>>>>>>>>>>>>>>>>> do the job, but have not tested it extensively.
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> It has been suggested to remove OSCsend and replace it with OSCsend2, so I would
>>>>>>>>>>>>>>>>>>>>>>>>>> like to check if OSCsend users could test OSCsend2 and let us know if there are differences
>>>>>>>>>>>>>>>>>>>>>>>>>> and whether it works OK for you. We would also then like to know whether having
>>>>>>>>>>>>>>>>>>>>>>>>>> OSCsend2 alongside OSCsend is your preference, or whether we should just replace it.
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>> Csound mailing list
>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>> Csound mailing list
>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>> Send bugs reports to
>>>>>>>>>>  https://github.com/csound/csound/issues
>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>> Csound mailing list
>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>> Send bugs reports to
>>>>>>>>>   https://github.com/csound/csound/issues
>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>> Csound mailing list
>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>> Send bugs reports to
>>>>>>>>   https://github.com/csound/csound/issues
>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>> Csound mailing list
>>>>>>> Csound@listserv.heanet.ie
>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>> Send bugs reports to
>>>>>>>    https://github.com/csound/csound/issues
>>>>>>> Discussions of bugs and features can be posted here
>>>>>> Csound mailing list
>>>>>> Csound@listserv.heanet.ie
>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>> Send bugs reports to
>>>>>>     https://github.com/csound/csound/issues
>>>>>> Discussions of bugs and features can be posted here
>>>>> Csound mailing list
>>>>> Csound@listserv.heanet.ie
>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>> Send bugs reports to
>>>>>      https://github.com/csound/csound/issues
>>>>> Discussions of bugs and features can be posted here
>>>> 
>>>> Csound mailing list
>>>> Csound@listserv.heanet.ie
>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>> Send bugs reports to
>>>>      https://github.com/csound/csound/issues
>>>> Discussions of bugs and features can be posted here
>>>> 
>>>> 
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>       https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>> 
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>        https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
> 
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here


Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

There was a mistake in the size setting, now (git) it should work as expected. The code below
reports 4 for dimension 2 (columns)

 giosc OSCinit 7770

instr	1
kwhen  init 0
kmetro metro 1
kwhen += kmetro
kArr[] init 8
kArr[0] = kwhen
kArr[1] = kwhen+1
kArr[2] = kwhen+2
kArr[3] = kwhen+3
OSCsend2 kwhen, "127.0.0.1",7770, "/foo/bar", "D",kArr
endin

instr 2
ktrig init 1
kArr[][] init 2,1
top:
ka OSClisten giosc, "/foo/bar","D", kArr
if ka > 0 then
ktrig += 1     
printk2 lenarray:k(kArr, 2)
endif
if ka > 0 kgoto top
endin
schedule(2,0,10)
schedule(1,0,10)


========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 7 Apr 2017, at 21:33, Victor Lazzarini  wrote:
> 
> I think it might be something to do with lenarray rather than this opcode. Try to
> access the extra members and you will see that they are there.
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952 
> 
>> On 7 Apr 2017, at 21:24, Guillermo Senna  wrote:
>> 
>> Yes, this one works fine. Although I tried growing the sending array
>> (1D) to 8 elements and at the receiving end the following sentence still
>> equals 4.
>> 
>> lenarray:i(kArr, 0) * lenarray:i(kArr)
>> 
>> Then I tried sending a 2D array (2 rows; 4 columns) but that doesn't
>> work as it doesn't receive [0][3] and [1][3]. I mean it's fine with me
>> as I don't need that feature. But maybe there should be a warning in the
>> future new man page.
>> 
>> 
>> On 07/04/17 16:57, Victor Lazzarini wrote:
>>> Here’s the code. Instrument 1 has a 4-element array and sends it over OSC to instrument 2.
>>> This one has a 2-dim array with 2 rows 1 column (2 elements). When the array is received,
>>> the columns grow to accommodate 2 extra numbers, turning this into a 2 x 2 matrix.
>>> 
>>> Note that if I don’t protect the printf call with an if …then, the first time the instrument
>>> is run wil give the index out of range message, because the message hasn’t been
>>> received yet. Once it is, the array grows. The rows never grow, only the columns (by design,
>>> since we have to choose one or the other).
>>> 
>>> giosc OSCinit 7770
>>> 
>>> instr	1
>>> kwhen  init 0
>>> kmetro metro 1
>>> kwhen += kmetro
>>> kArr[] init 4
>>> kArr[0] = kwhen
>>> kArr[1] = kwhen+1
>>> kArr[2] = kwhen+2
>>> kArr[3] = kwhen+3
>>> OSCsend2 kwhen, "127.0.0.1",7770, "/foo/bar", "D",kArr
>>> endin
>>> 
>>> instr 2
>>> ktrig init 1
>>> kArr[][] init 2,1
>>> top:
>>> ka OSClisten giosc, "/foo/bar","D", kArr
>>> if ka > 0 then
>>> printf "%d %d \n%d %d\n", ka*ktrig,
>>>    kArr[0][0], kArr[0][1], 
>>>    kArr[1][0], kArr[1][1]
>>> ktrig += 1     
>>> endif
>>> if ka > 0 kgoto top
>>> endin
>>> schedule(2,0,10)
>>> schedule(1,0,10)
>>> 
>>> 
>>> ========================
>>> Prof. Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy,
>>> Maynooth University,
>>> Maynooth, Co Kildare, Ireland
>>> Tel: 00 353 7086936
>>> Fax: 00 353 1 7086952 
>>> 
>>>> On 7 Apr 2017, at 19:40, Victor Lazzarini  wrote:
>>>> 
>>>> I tested here with a 2d array, with size 1 on each dimension, then passed an array with 4  numbers over OSC and dim 1 (number of columns) grew to accommodate it. I am away from the computer but when I have the chance I will post a test CSD.
>>>> 
>>>> Victor Lazzarini
>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>> Maynooth University
>>>> Ireland
>>>> 
>>>>> On 7 Apr 2017, at 19:27, Guillermo Senna  wrote:
>>>>> 
>>>>> I'm getting the same thing, Victor.  Could you try the test files I'm
>>>>> using? Maybe I'm expecting something that's not even possible.
>>>>> 
>>>>> 
>>>>>> On 07/04/17 05:00, Victor Lazzarini wrote:
>>>>>> I mean, not the higher ones!
>>>>>> ========================
>>>>>> Prof. Victor Lazzarini
>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>> Maynooth University,
>>>>>> Maynooth, Co Kildare, Ireland
>>>>>> Tel: 00 353 7086936
>>>>>> Fax: 00 353 1 7086952 
>>>>>> 
>>>>>>> On 7 Apr 2017, at 08:58, Victor Lazzarini  wrote:
>>>>>>> 
>>>>>>> Ok, I had things back to front. Now it should work as I planned. The first dimension of the array changes,
>>>>>>> not the lower ones. By first dimension I mean the columns in a row-column, ie. counting in the order in which the
>>>>>>> indexes appear from right to left.
>>>>>>> ========================
>>>>>>> Prof. Victor Lazzarini
>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>> Maynooth University,
>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>> Tel: 00 353 7086936
>>>>>>> Fax: 00 353 1 7086952 
>>>>>>> 
>>>>>>>> On 7 Apr 2017, at 08:02, Victor Lazzarini  wrote:
>>>>>>>> 
>>>>>>>> yes, I think I am mixing up dimension sizes, I will look. In any case, I will only be able to make one of the dimensions grow (as I can't guess how the matrix/cube/etc grows), whilst keeping the others fixed.
>>>>>>>> 
>>>>>>>> Victor Lazzarini
>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>>>>>> Maynooth University
>>>>>>>> Ireland
>>>>>>>> 
>>>>>>>>> On 7 Apr 2017, at 07:40, Guillermo Senna  wrote:
>>>>>>>>> 
>>>>>>>>> If I send a unidimensional array (from inside or outside Csound) it does
>>>>>>>>> grow organically!
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> On 07/04/17 02:39, Victor Lazzarini wrote:
>>>>>>>>>> It should be fixed now. The array was growing but I forgot to update the sizes.
>>>>>>>>>> ========================
>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>> Maynooth University,
>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>> 
>>>>>>>>>>> On 7 Apr 2017, at 06:16, Victor Lazzarini  wrote:
>>>>>>>>>>> 
>>>>>>>>>>> That shouldn't happen, the array should grow. I'll have a look and fix it.
>>>>>>>>>>> 
>>>>>>>>>>> Victor Lazzarini
>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>>>>>>>>> Maynooth University
>>>>>>>>>>> Ireland
>>>>>>>>>>> 
>>>>>>>>>>>> On 7 Apr 2017, at 04:30, Guillermo Senna  wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> I tested the new specifier from outside Csound. Now I understand what
>>>>>>>>>>>> you mean Victor. The good thing is that it forces you to choose a common
>>>>>>>>>>>> size between sender and receiver in advance and that prevents you from
>>>>>>>>>>>> getting "osc::OutOfBufferMemoryException" while sending exceedingly
>>>>>>>>>>>> large vectors. The bad thing is the need to process the received array
>>>>>>>>>>>> and look for a delimiter while sending variable-sized arrays like I'm
>>>>>>>>>>>> doing. Or maybe I can just send the size before through "/kArrSize" or
>>>>>>>>>>>> something like that.
>>>>>>>>>>>> 
>>>>>>>>>>>> Just for the record, with the "A" specifier you can do "kArr[] init 1"
>>>>>>>>>>>> and the array will still grow and shrink dynamically according to
>>>>>>>>>>>> dimensions/sizes received. That is very convenient. With the "D"
>>>>>>>>>>>> specifier you get "Array index 2 out of range (0,0) for dimension 1".
>>>>>>>>>>>> 
>>>>>>>>>>>> I've to think now how to effectively process the received the array, but
>>>>>>>>>>>> I think you saved me from a difficult-to-diagnose bug that I'd probably
>>>>>>>>>>>> have encountered in the future because of the UDP protocol.
>>>>>>>>>>>> 
>>>>>>>>>>>> I'll test OSCsend2 now. Cheers.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>> On 06/04/17 18:33, Victor Lazzarini wrote:
>>>>>>>>>>>>> Say you send 10 elements.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> You can interpret this as
>>>>>>>>>>>>> 
>>>>>>>>>>>>> [1,2,3,4,5,6,7,8,9,10]
>>>>>>>>>>>>> 
>>>>>>>>>>>>> or
>>>>>>>>>>>>> 
>>>>>>>>>>>>> [1,2]
>>>>>>>>>>>>> [3,4]
>>>>>>>>>>>>> [5,6]
>>>>>>>>>>>>> [7,8]
>>>>>>>>>>>>> 
>>>>>>>>>>>>> or
>>>>>>>>>>>>> 
>>>>>>>>>>>>> [1,2,3,4,5]
>>>>>>>>>>>>> [6,7,8,9,10]
>>>>>>>>>>>>> 
>>>>>>>>>>>>> or
>>>>>>>>>>>>> 
>>>>>>>>>>>>> [1,2,3]
>>>>>>>>>>>>> [4,5,6]
>>>>>>>>>>>>> [7,8,9]
>>>>>>>>>>>>> [10,0,0]
>>>>>>>>>>>>> 
>>>>>>>>>>>>> etc
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Whatever you do, if there isn’t enough size, the array grows dynamically. In the last
>>>>>>>>>>>>> example there was more than enough size, but we only copied  the 10 numbers
>>>>>>>>>>>>> we got.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I have added this type to OSClisten  and OSCsend2. 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> ========================
>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On 6 Apr 2017, at 22:20, Guillermo Senna  wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Oh, I see. And in the 2D version, if I send a single blob/array with:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 10 elements -> they all end up in dimension no. 1
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 30 elements -> they'd go 16-14
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 40 elements -> 16-24
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Or is it going to be an error not to match the dimensions/sizes?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On 06/04/17 18:10, Victor Lazzarini wrote:
>>>>>>>>>>>>>>> No, I mean
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> kArr[][] init 2, 16
>>>>>>>>>>>>>>> kk1  OSClisten gihandle, "/multiArr", "D", kArr
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> kArr[] init 32
>>>>>>>>>>>>>>> kk1  OSClisten gihandle, "/multiArr", "D", kArr
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> both working, the choice is yours
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On 6 Apr 2017, at 21:46, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> I'm not so sure I follow you with that last sentence. Do you mean
>>>>>>>>>>>>>>>> something like this could be possible?
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> kArr[][] init 2, 16
>>>>>>>>>>>>>>>> kk1  OSClisten gihandle, "/multiArr", "DD", kArr[0], kArr[1]
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On 06/04/17 17:36, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>> yes, same thing from the user perspective. Except that you can define how many dimensions you want
>>>>>>>>>>>>>>>>> to hold the data in.
>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On 6 Apr 2017, at 21:33, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> I like that. Non of those characters are really part of the OSC
>>>>>>>>>>>>>>>>>> specification, so why not?
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> But with this approach you would still use a Csound array as xdata1 in
>>>>>>>>>>>>>>>>>> OSClisten, right?
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> On 06/04/17 17:16, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>>> We could put in a different type name for non-descript double-format data sequence (e.g. 2), for instance
>>>>>>>>>>>>>>>>>>> call it “D”.
>>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> On 6 Apr 2017, at 21:04, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> I've not considered number 2 before. How about adding an opcode later
>>>>>>>>>>>>>>>>>>>> for joining 2d arrays into a single multidimensional? Would it be to
>>>>>>>>>>>>>>>>>>>> difficult/inefficient to do that considering that in the end it's all
>>>>>>>>>>>>>>>>>>>> about pointers?
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> I don't want to change and break it for others already using the current
>>>>>>>>>>>>>>>>>>>> structure.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> On 05/04/17 18:12, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>>>>> I see what you mean. It’s possible to change it, there are two options:
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 1) encode everything with doubles
>>>>>>>>>>>>>>>>>>>>> 2) leave dim and size. The size of the blob is always there before the
>>>>>>>>>>>>>>>>>>>>> data, so we can just use that. It will be then up to the user to interpret
>>>>>>>>>>>>>>>>>>>>> the data as a 1,2,3 ,… dimensional array. The data is always stored
>>>>>>>>>>>>>>>>>>>>> as a flat vector (e.g. row-column for 2-d).
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> if people want it changed, I can do it.
>>>>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> On 5 Apr 2017, at 18:24, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> My reasoning is that in the different programming languages you'd use a
>>>>>>>>>>>>>>>>>>>>>> library/module for handling the OSC part and that would in turn have
>>>>>>>>>>>>>>>>>>>>>> some abstraction for sending entire arrays as blobs. Now, Csound
>>>>>>>>>>>>>>>>>>>>>> requests for two 32-bit ints and then the rest 64-bits doubles. Is that
>>>>>>>>>>>>>>>>>>>>>> always possible to control in the higher-level languages?
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> Initially what I'd have thought is that I could build an array with all
>>>>>>>>>>>>>>>>>>>>>> doubles and Csound would internally truncate the first two values and
>>>>>>>>>>>>>>>>>>>>>> cast them into ints.
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> But if it's working for everyone right now nothing should be changed!
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> On 05/04/17 14:04, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>>>>>>> Well, Csound reads two ints, as far as I can see. So I would expect that you can just send two
>>>>>>>>>>>>>>>>>>>>>>> separate ints and Csound would understand it (first the dimension, then the size). This is
>>>>>>>>>>>>>>>>>>>>>>> what OSCsend2 (& OSCsend) does. Not quite sure what might be going on at your end.
>>>>>>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> On 5 Apr 2017, at 17:44, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> Well I'm doing it in C++ with oscpack and for me it works. Now, I don't
>>>>>>>>>>>>>>>>>>>>>>>> know much about python for example, but if you are using a python module
>>>>>>>>>>>>>>>>>>>>>>>> for handling the OSC part of your program, is it possible to construct
>>>>>>>>>>>>>>>>>>>>>>>> the array to be sent as two ints and the rest as doubles?
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> I'm asking from complete ignorance, Victor. It just seemed odd to
>>>>>>>>>>>>>>>>>>>>>>>> (instead of passing my entire vector in C++) have to do something like this:
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> unsigned long ui = qvlist.size();
>>>>>>>>>>>>>>>>>>>>>>>> ui <<= 32; ui |= 1;
>>>>>>>>>>>>>>>>>>>>>>>> vec.push_back (*(double*)&ui);
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> On 05/04/17 13:30, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> I have implemented the array, audio and function table as per OSCsend/OSClisten. As far as I can see from the code, the blob is as you
>>>>>>>>>>>>>>>>>>>>>>>>> describe, all data being sent in the native endianess (little endian for i386/x86_64). It could be that the OSC lib is expecting the data
>>>>>>>>>>>>>>>>>>>>>>>>> in big-endian ints, 4 bytes at a time. As far as I understand, the OSC should not impose any particular interpretation to the blob,
>>>>>>>>>>>>>>>>>>>>>>>>> but just take it as a string of bytes.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> On 5 Apr 2017, at 17:03, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> I'll try it in a few moments. Are you going to replace OSClisten too? If
>>>>>>>>>>>>>>>>>>>>>>>>>> you do, please beware that right now receiving an array in Csound
>>>>>>>>>>>>>>>>>>>>>>>>>> expects the structure [dimensions(int); size(int); values(double)...]. I
>>>>>>>>>>>>>>>>>>>>>>>>>> had to bitshift and cast two ints as a double in order to make that work
>>>>>>>>>>>>>>>>>>>>>>>>>> from a third-party OSC library outside Csound. It didn't seem right and
>>>>>>>>>>>>>>>>>>>>>>>>>> I don't think it's possible in every programming language.
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> Cheers.
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 05/04/17 08:30, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> Following our conclusion that liblo seems to be overly heavy weight for OSC sending, I have
>>>>>>>>>>>>>>>>>>>>>>>>>>> implemented an alternative version that uses UDP sockets directly. It is currently called
>>>>>>>>>>>>>>>>>>>>>>>>>>> OSCsend2 and the interface is exactly the same to OSCsend. In our tests, it appears to
>>>>>>>>>>>>>>>>>>>>>>>>>>> do the job, but have not tested it extensively.
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> It has been suggested to remove OSCsend and replace it with OSCsend2, so I would
>>>>>>>>>>>>>>>>>>>>>>>>>>> like to check if OSCsend users could test OSCsend2 and let us know if there are differences
>>>>>>>>>>>>>>>>>>>>>>>>>>> and whether it works OK for you. We would also then like to know whether having
>>>>>>>>>>>>>>>>>>>>>>>>>>> OSCsend2 alongside OSCsend is your preference, or whether we should just replace it.
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>> Csound mailing list
>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>> Csound mailing list
>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>> Send bugs reports to
>>>>>>>>>>  https://github.com/csound/csound/issues
>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>> Csound mailing list
>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>> Send bugs reports to
>>>>>>>>>  https://github.com/csound/csound/issues
>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>> Csound mailing list
>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>> Send bugs reports to
>>>>>>>>   https://github.com/csound/csound/issues
>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>> Csound mailing list
>>>>>>> Csound@listserv.heanet.ie
>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>> Send bugs reports to
>>>>>>>    https://github.com/csound/csound/issues
>>>>>>> Discussions of bugs and features can be posted here
>>>>>> Csound mailing list
>>>>>> Csound@listserv.heanet.ie
>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>> Send bugs reports to
>>>>>>     https://github.com/csound/csound/issues
>>>>>> Discussions of bugs and features can be posted here
>>>>> 
>>>>> Csound mailing list
>>>>> Csound@listserv.heanet.ie
>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>> Send bugs reports to
>>>>>     https://github.com/csound/csound/issues
>>>>> Discussions of bugs and features can be posted here
>>>>> 
>>>>> 
>>>> Csound mailing list
>>>> Csound@listserv.heanet.ie
>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>> Send bugs reports to
>>>>      https://github.com/csound/csound/issues
>>>> Discussions of bugs and features can be posted here
>>> 
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>       https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>> 
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>       https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
> 
> 
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here


Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

For multidimensional arrays lenarray:k(kArr, 1) and lenarray:k(kArr) are
the ones that don't output the right thing. They give you the number of
dimensions instead of the size of the 1st column.

On 07/04/17 17:33, Victor Lazzarini wrote:
> I think it might be something to do with lenarray rather than this opcode. Try to
> access the extra members and you will see that they are there.
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952 
>
>> On 7 Apr 2017, at 21:24, Guillermo Senna  wrote:
>>
>> Yes, this one works fine. Although I tried growing the sending array
>> (1D) to 8 elements and at the receiving end the following sentence still
>> equals 4.
>>
>> lenarray:i(kArr, 0) * lenarray:i(kArr)
>>
>> Then I tried sending a 2D array (2 rows; 4 columns) but that doesn't
>> work as it doesn't receive [0][3] and [1][3]. I mean it's fine with me
>> as I don't need that feature. But maybe there should be a warning in the
>> future new man page.
>>
>>
>> On 07/04/17 16:57, Victor Lazzarini wrote:
>>> Here’s the code. Instrument 1 has a 4-element array and sends it over OSC to instrument 2.
>>> This one has a 2-dim array with 2 rows 1 column (2 elements). When the array is received,
>>> the columns grow to accommodate 2 extra numbers, turning this into a 2 x 2 matrix.
>>>
>>> Note that if I don’t protect the printf call with an if …then, the first time the instrument
>>> is run wil give the index out of range message, because the message hasn’t been
>>> received yet. Once it is, the array grows. The rows never grow, only the columns (by design,
>>> since we have to choose one or the other).
>>>
>>> giosc OSCinit 7770
>>>
>>> instr	1
>>> kwhen  init 0
>>> kmetro metro 1
>>> kwhen += kmetro
>>> kArr[] init 4
>>> kArr[0] = kwhen
>>> kArr[1] = kwhen+1
>>> kArr[2] = kwhen+2
>>> kArr[3] = kwhen+3
>>> OSCsend2 kwhen, "127.0.0.1",7770, "/foo/bar", "D",kArr
>>> endin
>>>
>>> instr 2
>>> ktrig init 1
>>> kArr[][] init 2,1
>>> top:
>>> ka OSClisten giosc, "/foo/bar","D", kArr
>>> if ka > 0 then
>>> printf "%d %d \n%d %d\n", ka*ktrig,
>>>     kArr[0][0], kArr[0][1], 
>>>     kArr[1][0], kArr[1][1]
>>> ktrig += 1     
>>> endif
>>> if ka > 0 kgoto top
>>> endin
>>> schedule(2,0,10)
>>> schedule(1,0,10)
>>>
>>>
>>> ========================
>>> Prof. Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy,
>>> Maynooth University,
>>> Maynooth, Co Kildare, Ireland
>>> Tel: 00 353 7086936
>>> Fax: 00 353 1 7086952 
>>>
>>>> On 7 Apr 2017, at 19:40, Victor Lazzarini  wrote:
>>>>
>>>> I tested here with a 2d array, with size 1 on each dimension, then passed an array with 4  numbers over OSC and dim 1 (number of columns) grew to accommodate it. I am away from the computer but when I have the chance I will post a test CSD.
>>>>
>>>> Victor Lazzarini
>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>> Maynooth University
>>>> Ireland
>>>>
>>>>> On 7 Apr 2017, at 19:27, Guillermo Senna  wrote:
>>>>>
>>>>> I'm getting the same thing, Victor.  Could you try the test files I'm
>>>>> using? Maybe I'm expecting something that's not even possible.
>>>>>
>>>>>
>>>>>> On 07/04/17 05:00, Victor Lazzarini wrote:
>>>>>> I mean, not the higher ones!
>>>>>> ========================
>>>>>> Prof. Victor Lazzarini
>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>> Maynooth University,
>>>>>> Maynooth, Co Kildare, Ireland
>>>>>> Tel: 00 353 7086936
>>>>>> Fax: 00 353 1 7086952 
>>>>>>
>>>>>>> On 7 Apr 2017, at 08:58, Victor Lazzarini  wrote:
>>>>>>>
>>>>>>> Ok, I had things back to front. Now it should work as I planned. The first dimension of the array changes,
>>>>>>> not the lower ones. By first dimension I mean the columns in a row-column, ie. counting in the order in which the
>>>>>>> indexes appear from right to left.
>>>>>>> ========================
>>>>>>> Prof. Victor Lazzarini
>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>> Maynooth University,
>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>> Tel: 00 353 7086936
>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>
>>>>>>>> On 7 Apr 2017, at 08:02, Victor Lazzarini  wrote:
>>>>>>>>
>>>>>>>> yes, I think I am mixing up dimension sizes, I will look. In any case, I will only be able to make one of the dimensions grow (as I can't guess how the matrix/cube/etc grows), whilst keeping the others fixed.
>>>>>>>>
>>>>>>>> Victor Lazzarini
>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>>>>>> Maynooth University
>>>>>>>> Ireland
>>>>>>>>
>>>>>>>>> On 7 Apr 2017, at 07:40, Guillermo Senna  wrote:
>>>>>>>>>
>>>>>>>>> If I send a unidimensional array (from inside or outside Csound) it does
>>>>>>>>> grow organically!
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On 07/04/17 02:39, Victor Lazzarini wrote:
>>>>>>>>>> It should be fixed now. The array was growing but I forgot to update the sizes.
>>>>>>>>>> ========================
>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>> Maynooth University,
>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>
>>>>>>>>>>> On 7 Apr 2017, at 06:16, Victor Lazzarini  wrote:
>>>>>>>>>>>
>>>>>>>>>>> That shouldn't happen, the array should grow. I'll have a look and fix it.
>>>>>>>>>>>
>>>>>>>>>>> Victor Lazzarini
>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>>>>>>>>> Maynooth University
>>>>>>>>>>> Ireland
>>>>>>>>>>>
>>>>>>>>>>>> On 7 Apr 2017, at 04:30, Guillermo Senna  wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> I tested the new specifier from outside Csound. Now I understand what
>>>>>>>>>>>> you mean Victor. The good thing is that it forces you to choose a common
>>>>>>>>>>>> size between sender and receiver in advance and that prevents you from
>>>>>>>>>>>> getting "osc::OutOfBufferMemoryException" while sending exceedingly
>>>>>>>>>>>> large vectors. The bad thing is the need to process the received array
>>>>>>>>>>>> and look for a delimiter while sending variable-sized arrays like I'm
>>>>>>>>>>>> doing. Or maybe I can just send the size before through "/kArrSize" or
>>>>>>>>>>>> something like that.
>>>>>>>>>>>>
>>>>>>>>>>>> Just for the record, with the "A" specifier you can do "kArr[] init 1"
>>>>>>>>>>>> and the array will still grow and shrink dynamically according to
>>>>>>>>>>>> dimensions/sizes received. That is very convenient. With the "D"
>>>>>>>>>>>> specifier you get "Array index 2 out of range (0,0) for dimension 1".
>>>>>>>>>>>>
>>>>>>>>>>>> I've to think now how to effectively process the received the array, but
>>>>>>>>>>>> I think you saved me from a difficult-to-diagnose bug that I'd probably
>>>>>>>>>>>> have encountered in the future because of the UDP protocol.
>>>>>>>>>>>>
>>>>>>>>>>>> I'll test OSCsend2 now. Cheers.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> On 06/04/17 18:33, Victor Lazzarini wrote:
>>>>>>>>>>>>> Say you send 10 elements.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You can interpret this as
>>>>>>>>>>>>>
>>>>>>>>>>>>> [1,2,3,4,5,6,7,8,9,10]
>>>>>>>>>>>>>
>>>>>>>>>>>>> or
>>>>>>>>>>>>>
>>>>>>>>>>>>> [1,2]
>>>>>>>>>>>>> [3,4]
>>>>>>>>>>>>> [5,6]
>>>>>>>>>>>>> [7,8]
>>>>>>>>>>>>>
>>>>>>>>>>>>> or
>>>>>>>>>>>>>
>>>>>>>>>>>>> [1,2,3,4,5]
>>>>>>>>>>>>> [6,7,8,9,10]
>>>>>>>>>>>>>
>>>>>>>>>>>>> or
>>>>>>>>>>>>>
>>>>>>>>>>>>> [1,2,3]
>>>>>>>>>>>>> [4,5,6]
>>>>>>>>>>>>> [7,8,9]
>>>>>>>>>>>>> [10,0,0]
>>>>>>>>>>>>>
>>>>>>>>>>>>> etc
>>>>>>>>>>>>>
>>>>>>>>>>>>> Whatever you do, if there isn’t enough size, the array grows dynamically. In the last
>>>>>>>>>>>>> example there was more than enough size, but we only copied  the 10 numbers
>>>>>>>>>>>>> we got.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have added this type to OSClisten  and OSCsend2. 
>>>>>>>>>>>>>
>>>>>>>>>>>>> ========================
>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 6 Apr 2017, at 22:20, Guillermo Senna  wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Oh, I see. And in the 2D version, if I send a single blob/array with:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 10 elements -> they all end up in dimension no. 1
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 30 elements -> they'd go 16-14
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 40 elements -> 16-24
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Or is it going to be an error not to match the dimensions/sizes?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 06/04/17 18:10, Victor Lazzarini wrote:
>>>>>>>>>>>>>>> No, I mean
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> kArr[][] init 2, 16
>>>>>>>>>>>>>>> kk1  OSClisten gihandle, "/multiArr", "D", kArr
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> kArr[] init 32
>>>>>>>>>>>>>>> kk1  OSClisten gihandle, "/multiArr", "D", kArr
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> both working, the choice is yours
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 6 Apr 2017, at 21:46, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'm not so sure I follow you with that last sentence. Do you mean
>>>>>>>>>>>>>>>> something like this could be possible?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> kArr[][] init 2, 16
>>>>>>>>>>>>>>>> kk1  OSClisten gihandle, "/multiArr", "DD", kArr[0], kArr[1]
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 06/04/17 17:36, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>> yes, same thing from the user perspective. Except that you can define how many dimensions you want
>>>>>>>>>>>>>>>>> to hold the data in.
>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 6 Apr 2017, at 21:33, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I like that. Non of those characters are really part of the OSC
>>>>>>>>>>>>>>>>>> specification, so why not?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> But with this approach you would still use a Csound array as xdata1 in
>>>>>>>>>>>>>>>>>> OSClisten, right?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 06/04/17 17:16, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>>> We could put in a different type name for non-descript double-format data sequence (e.g. 2), for instance
>>>>>>>>>>>>>>>>>>> call it “D”.
>>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 6 Apr 2017, at 21:04, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I've not considered number 2 before. How about adding an opcode later
>>>>>>>>>>>>>>>>>>>> for joining 2d arrays into a single multidimensional? Would it be to
>>>>>>>>>>>>>>>>>>>> difficult/inefficient to do that considering that in the end it's all
>>>>>>>>>>>>>>>>>>>> about pointers?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I don't want to change and break it for others already using the current
>>>>>>>>>>>>>>>>>>>> structure.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 05/04/17 18:12, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>>>>> I see what you mean. It’s possible to change it, there are two options:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 1) encode everything with doubles
>>>>>>>>>>>>>>>>>>>>> 2) leave dim and size. The size of the blob is always there before the
>>>>>>>>>>>>>>>>>>>>> data, so we can just use that. It will be then up to the user to interpret
>>>>>>>>>>>>>>>>>>>>> the data as a 1,2,3 ,… dimensional array. The data is always stored
>>>>>>>>>>>>>>>>>>>>> as a flat vector (e.g. row-column for 2-d).
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> if people want it changed, I can do it.
>>>>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 5 Apr 2017, at 18:24, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> My reasoning is that in the different programming languages you'd use a
>>>>>>>>>>>>>>>>>>>>>> library/module for handling the OSC part and that would in turn have
>>>>>>>>>>>>>>>>>>>>>> some abstraction for sending entire arrays as blobs. Now, Csound
>>>>>>>>>>>>>>>>>>>>>> requests for two 32-bit ints and then the rest 64-bits doubles. Is that
>>>>>>>>>>>>>>>>>>>>>> always possible to control in the higher-level languages?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Initially what I'd have thought is that I could build an array with all
>>>>>>>>>>>>>>>>>>>>>> doubles and Csound would internally truncate the first two values and
>>>>>>>>>>>>>>>>>>>>>> cast them into ints.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> But if it's working for everyone right now nothing should be changed!
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 05/04/17 14:04, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>>>>>>> Well, Csound reads two ints, as far as I can see. So I would expect that you can just send two
>>>>>>>>>>>>>>>>>>>>>>> separate ints and Csound would understand it (first the dimension, then the size). This is
>>>>>>>>>>>>>>>>>>>>>>> what OSCsend2 (& OSCsend) does. Not quite sure what might be going on at your end.
>>>>>>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On 5 Apr 2017, at 17:44, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Well I'm doing it in C++ with oscpack and for me it works. Now, I don't
>>>>>>>>>>>>>>>>>>>>>>>> know much about python for example, but if you are using a python module
>>>>>>>>>>>>>>>>>>>>>>>> for handling the OSC part of your program, is it possible to construct
>>>>>>>>>>>>>>>>>>>>>>>> the array to be sent as two ints and the rest as doubles?
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I'm asking from complete ignorance, Victor. It just seemed odd to
>>>>>>>>>>>>>>>>>>>>>>>> (instead of passing my entire vector in C++) have to do something like this:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> unsigned long ui = qvlist.size();
>>>>>>>>>>>>>>>>>>>>>>>> ui <<= 32; ui |= 1;
>>>>>>>>>>>>>>>>>>>>>>>> vec.push_back (*(double*)&ui);
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On 05/04/17 13:30, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> I have implemented the array, audio and function table as per OSCsend/OSClisten. As far as I can see from the code, the blob is as you
>>>>>>>>>>>>>>>>>>>>>>>>> describe, all data being sent in the native endianess (little endian for i386/x86_64). It could be that the OSC lib is expecting the data
>>>>>>>>>>>>>>>>>>>>>>>>> in big-endian ints, 4 bytes at a time. As far as I understand, the OSC should not impose any particular interpretation to the blob,
>>>>>>>>>>>>>>>>>>>>>>>>> but just take it as a string of bytes.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> On 5 Apr 2017, at 17:03, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> I'll try it in a few moments. Are you going to replace OSClisten too? If
>>>>>>>>>>>>>>>>>>>>>>>>>> you do, please beware that right now receiving an array in Csound
>>>>>>>>>>>>>>>>>>>>>>>>>> expects the structure [dimensions(int); size(int); values(double)...]. I
>>>>>>>>>>>>>>>>>>>>>>>>>> had to bitshift and cast two ints as a double in order to make that work
>>>>>>>>>>>>>>>>>>>>>>>>>> from a third-party OSC library outside Csound. It didn't seem right and
>>>>>>>>>>>>>>>>>>>>>>>>>> I don't think it's possible in every programming language.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Cheers.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 05/04/17 08:30, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> Following our conclusion that liblo seems to be overly heavy weight for OSC sending, I have
>>>>>>>>>>>>>>>>>>>>>>>>>>> implemented an alternative version that uses UDP sockets directly. It is currently called
>>>>>>>>>>>>>>>>>>>>>>>>>>> OSCsend2 and the interface is exactly the same to OSCsend. In our tests, it appears to
>>>>>>>>>>>>>>>>>>>>>>>>>>> do the job, but have not tested it extensively.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> It has been suggested to remove OSCsend and replace it with OSCsend2, so I would
>>>>>>>>>>>>>>>>>>>>>>>>>>> like to check if OSCsend users could test OSCsend2 and let us know if there are differences
>>>>>>>>>>>>>>>>>>>>>>>>>>> and whether it works OK for you. We would also then like to know whether having
>>>>>>>>>>>>>>>>>>>>>>>>>>> OSCsend2 alongside OSCsend is your preference, or whether we should just replace it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>> Csound mailing list
>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>  https://github.com/csound/csound/issues
>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>> Csound mailing list
>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>> Send bugs reports to
>>>>>>>>>>   https://github.com/csound/csound/issues
>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>> Csound mailing list
>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>> Send bugs reports to
>>>>>>>>>   https://github.com/csound/csound/issues
>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>> Csound mailing list
>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>> Send bugs reports to
>>>>>>>>    https://github.com/csound/csound/issues
>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>> Csound mailing list
>>>>>>> Csound@listserv.heanet.ie
>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>> Send bugs reports to
>>>>>>>     https://github.com/csound/csound/issues
>>>>>>> Discussions of bugs and features can be posted here
>>>>>> Csound mailing list
>>>>>> Csound@listserv.heanet.ie
>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>> Send bugs reports to
>>>>>>      https://github.com/csound/csound/issues
>>>>>> Discussions of bugs and features can be posted here
>>>>> Csound mailing list
>>>>> Csound@listserv.heanet.ie
>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>> Send bugs reports to
>>>>>      https://github.com/csound/csound/issues
>>>>> Discussions of bugs and features can be posted here
>>>>> 
>>>>> 
>>>> Csound mailing list
>>>> Csound@listserv.heanet.ie
>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>> Send bugs reports to
>>>>       https://github.com/csound/csound/issues
>>>> Discussions of bugs and features can be posted here
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>        https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>        https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Rows are 1 and columns 2 in this case. The code I fixed should work now
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 7 Apr 2017, at 21:50, Guillermo Senna  wrote:
> 
> For multidimensional arrays lenarray:k(kArr, 1) and lenarray:k(kArr) are
> the ones that don't output the right thing. They give you the number of
> dimensions instead of the size of the 1st column.
> 
> On 07/04/17 17:33, Victor Lazzarini wrote:
>> I think it might be something to do with lenarray rather than this opcode. Try to
>> access the extra members and you will see that they are there.
>> ========================
>> Prof. Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy,
>> Maynooth University,
>> Maynooth, Co Kildare, Ireland
>> Tel: 00 353 7086936
>> Fax: 00 353 1 7086952 
>> 
>>> On 7 Apr 2017, at 21:24, Guillermo Senna  wrote:
>>> 
>>> Yes, this one works fine. Although I tried growing the sending array
>>> (1D) to 8 elements and at the receiving end the following sentence still
>>> equals 4.
>>> 
>>> lenarray:i(kArr, 0) * lenarray:i(kArr)
>>> 
>>> Then I tried sending a 2D array (2 rows; 4 columns) but that doesn't
>>> work as it doesn't receive [0][3] and [1][3]. I mean it's fine with me
>>> as I don't need that feature. But maybe there should be a warning in the
>>> future new man page.
>>> 
>>> 
>>> On 07/04/17 16:57, Victor Lazzarini wrote:
>>>> Here’s the code. Instrument 1 has a 4-element array and sends it over OSC to instrument 2.
>>>> This one has a 2-dim array with 2 rows 1 column (2 elements). When the array is received,
>>>> the columns grow to accommodate 2 extra numbers, turning this into a 2 x 2 matrix.
>>>> 
>>>> Note that if I don’t protect the printf call with an if …then, the first time the instrument
>>>> is run wil give the index out of range message, because the message hasn’t been
>>>> received yet. Once it is, the array grows. The rows never grow, only the columns (by design,
>>>> since we have to choose one or the other).
>>>> 
>>>> giosc OSCinit 7770
>>>> 
>>>> instr	1
>>>> kwhen  init 0
>>>> kmetro metro 1
>>>> kwhen += kmetro
>>>> kArr[] init 4
>>>> kArr[0] = kwhen
>>>> kArr[1] = kwhen+1
>>>> kArr[2] = kwhen+2
>>>> kArr[3] = kwhen+3
>>>> OSCsend2 kwhen, "127.0.0.1",7770, "/foo/bar", "D",kArr
>>>> endin
>>>> 
>>>> instr 2
>>>> ktrig init 1
>>>> kArr[][] init 2,1
>>>> top:
>>>> ka OSClisten giosc, "/foo/bar","D", kArr
>>>> if ka > 0 then
>>>> printf "%d %d \n%d %d\n", ka*ktrig,
>>>>    kArr[0][0], kArr[0][1], 
>>>>    kArr[1][0], kArr[1][1]
>>>> ktrig += 1     
>>>> endif
>>>> if ka > 0 kgoto top
>>>> endin
>>>> schedule(2,0,10)
>>>> schedule(1,0,10)
>>>> 
>>>> 
>>>> ========================
>>>> Prof. Victor Lazzarini
>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>> Maynooth University,
>>>> Maynooth, Co Kildare, Ireland
>>>> Tel: 00 353 7086936
>>>> Fax: 00 353 1 7086952 
>>>> 
>>>>> On 7 Apr 2017, at 19:40, Victor Lazzarini  wrote:
>>>>> 
>>>>> I tested here with a 2d array, with size 1 on each dimension, then passed an array with 4  numbers over OSC and dim 1 (number of columns) grew to accommodate it. I am away from the computer but when I have the chance I will post a test CSD.
>>>>> 
>>>>> Victor Lazzarini
>>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>>> Maynooth University
>>>>> Ireland
>>>>> 
>>>>>> On 7 Apr 2017, at 19:27, Guillermo Senna  wrote:
>>>>>> 
>>>>>> I'm getting the same thing, Victor.  Could you try the test files I'm
>>>>>> using? Maybe I'm expecting something that's not even possible.
>>>>>> 
>>>>>> 
>>>>>>> On 07/04/17 05:00, Victor Lazzarini wrote:
>>>>>>> I mean, not the higher ones!
>>>>>>> ========================
>>>>>>> Prof. Victor Lazzarini
>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>> Maynooth University,
>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>> Tel: 00 353 7086936
>>>>>>> Fax: 00 353 1 7086952 
>>>>>>> 
>>>>>>>> On 7 Apr 2017, at 08:58, Victor Lazzarini  wrote:
>>>>>>>> 
>>>>>>>> Ok, I had things back to front. Now it should work as I planned. The first dimension of the array changes,
>>>>>>>> not the lower ones. By first dimension I mean the columns in a row-column, ie. counting in the order in which the
>>>>>>>> indexes appear from right to left.
>>>>>>>> ========================
>>>>>>>> Prof. Victor Lazzarini
>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>> Maynooth University,
>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>> Tel: 00 353 7086936
>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>> 
>>>>>>>>> On 7 Apr 2017, at 08:02, Victor Lazzarini  wrote:
>>>>>>>>> 
>>>>>>>>> yes, I think I am mixing up dimension sizes, I will look. In any case, I will only be able to make one of the dimensions grow (as I can't guess how the matrix/cube/etc grows), whilst keeping the others fixed.
>>>>>>>>> 
>>>>>>>>> Victor Lazzarini
>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>>>>>>> Maynooth University
>>>>>>>>> Ireland
>>>>>>>>> 
>>>>>>>>>> On 7 Apr 2017, at 07:40, Guillermo Senna  wrote:
>>>>>>>>>> 
>>>>>>>>>> If I send a unidimensional array (from inside or outside Csound) it does
>>>>>>>>>> grow organically!
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> On 07/04/17 02:39, Victor Lazzarini wrote:
>>>>>>>>>>> It should be fixed now. The array was growing but I forgot to update the sizes.
>>>>>>>>>>> ========================
>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>> Maynooth University,
>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>> 
>>>>>>>>>>>> On 7 Apr 2017, at 06:16, Victor Lazzarini  wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> That shouldn't happen, the array should grow. I'll have a look and fix it.
>>>>>>>>>>>> 
>>>>>>>>>>>> Victor Lazzarini
>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>>>>>>>>>> Maynooth University
>>>>>>>>>>>> Ireland
>>>>>>>>>>>> 
>>>>>>>>>>>>> On 7 Apr 2017, at 04:30, Guillermo Senna  wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I tested the new specifier from outside Csound. Now I understand what
>>>>>>>>>>>>> you mean Victor. The good thing is that it forces you to choose a common
>>>>>>>>>>>>> size between sender and receiver in advance and that prevents you from
>>>>>>>>>>>>> getting "osc::OutOfBufferMemoryException" while sending exceedingly
>>>>>>>>>>>>> large vectors. The bad thing is the need to process the received array
>>>>>>>>>>>>> and look for a delimiter while sending variable-sized arrays like I'm
>>>>>>>>>>>>> doing. Or maybe I can just send the size before through "/kArrSize" or
>>>>>>>>>>>>> something like that.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Just for the record, with the "A" specifier you can do "kArr[] init 1"
>>>>>>>>>>>>> and the array will still grow and shrink dynamically according to
>>>>>>>>>>>>> dimensions/sizes received. That is very convenient. With the "D"
>>>>>>>>>>>>> specifier you get "Array index 2 out of range (0,0) for dimension 1".
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I've to think now how to effectively process the received the array, but
>>>>>>>>>>>>> I think you saved me from a difficult-to-diagnose bug that I'd probably
>>>>>>>>>>>>> have encountered in the future because of the UDP protocol.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I'll test OSCsend2 now. Cheers.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On 06/04/17 18:33, Victor Lazzarini wrote:
>>>>>>>>>>>>>> Say you send 10 elements.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> You can interpret this as
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> [1,2,3,4,5,6,7,8,9,10]
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> or
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> [1,2]
>>>>>>>>>>>>>> [3,4]
>>>>>>>>>>>>>> [5,6]
>>>>>>>>>>>>>> [7,8]
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> or
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> [1,2,3,4,5]
>>>>>>>>>>>>>> [6,7,8,9,10]
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> or
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> [1,2,3]
>>>>>>>>>>>>>> [4,5,6]
>>>>>>>>>>>>>> [7,8,9]
>>>>>>>>>>>>>> [10,0,0]
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> etc
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Whatever you do, if there isn’t enough size, the array grows dynamically. In the last
>>>>>>>>>>>>>> example there was more than enough size, but we only copied  the 10 numbers
>>>>>>>>>>>>>> we got.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I have added this type to OSClisten  and OSCsend2. 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On 6 Apr 2017, at 22:20, Guillermo Senna  wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Oh, I see. And in the 2D version, if I send a single blob/array with:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 10 elements -> they all end up in dimension no. 1
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 30 elements -> they'd go 16-14
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 40 elements -> 16-24
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Or is it going to be an error not to match the dimensions/sizes?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On 06/04/17 18:10, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>> No, I mean
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> kArr[][] init 2, 16
>>>>>>>>>>>>>>>> kk1  OSClisten gihandle, "/multiArr", "D", kArr
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> kArr[] init 32
>>>>>>>>>>>>>>>> kk1  OSClisten gihandle, "/multiArr", "D", kArr
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> both working, the choice is yours
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On 6 Apr 2017, at 21:46, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> I'm not so sure I follow you with that last sentence. Do you mean
>>>>>>>>>>>>>>>>> something like this could be possible?
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> kArr[][] init 2, 16
>>>>>>>>>>>>>>>>> kk1  OSClisten gihandle, "/multiArr", "DD", kArr[0], kArr[1]
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On 06/04/17 17:36, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>> yes, same thing from the user perspective. Except that you can define how many dimensions you want
>>>>>>>>>>>>>>>>>> to hold the data in.
>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> On 6 Apr 2017, at 21:33, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> I like that. Non of those characters are really part of the OSC
>>>>>>>>>>>>>>>>>>> specification, so why not?
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> But with this approach you would still use a Csound array as xdata1 in
>>>>>>>>>>>>>>>>>>> OSClisten, right?
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> On 06/04/17 17:16, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>>>> We could put in a different type name for non-descript double-format data sequence (e.g. 2), for instance
>>>>>>>>>>>>>>>>>>>> call it “D”.
>>>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> On 6 Apr 2017, at 21:04, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> I've not considered number 2 before. How about adding an opcode later
>>>>>>>>>>>>>>>>>>>>> for joining 2d arrays into a single multidimensional? Would it be to
>>>>>>>>>>>>>>>>>>>>> difficult/inefficient to do that considering that in the end it's all
>>>>>>>>>>>>>>>>>>>>> about pointers?
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> I don't want to change and break it for others already using the current
>>>>>>>>>>>>>>>>>>>>> structure.
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> On 05/04/17 18:12, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>>>>>> I see what you mean. It’s possible to change it, there are two options:
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 1) encode everything with doubles
>>>>>>>>>>>>>>>>>>>>>> 2) leave dim and size. The size of the blob is always there before the
>>>>>>>>>>>>>>>>>>>>>> data, so we can just use that. It will be then up to the user to interpret
>>>>>>>>>>>>>>>>>>>>>> the data as a 1,2,3 ,… dimensional array. The data is always stored
>>>>>>>>>>>>>>>>>>>>>> as a flat vector (e.g. row-column for 2-d).
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> if people want it changed, I can do it.
>>>>>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> On 5 Apr 2017, at 18:24, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> My reasoning is that in the different programming languages you'd use a
>>>>>>>>>>>>>>>>>>>>>>> library/module for handling the OSC part and that would in turn have
>>>>>>>>>>>>>>>>>>>>>>> some abstraction for sending entire arrays as blobs. Now, Csound
>>>>>>>>>>>>>>>>>>>>>>> requests for two 32-bit ints and then the rest 64-bits doubles. Is that
>>>>>>>>>>>>>>>>>>>>>>> always possible to control in the higher-level languages?
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> Initially what I'd have thought is that I could build an array with all
>>>>>>>>>>>>>>>>>>>>>>> doubles and Csound would internally truncate the first two values and
>>>>>>>>>>>>>>>>>>>>>>> cast them into ints.
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> But if it's working for everyone right now nothing should be changed!
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> On 05/04/17 14:04, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>>>>>>>> Well, Csound reads two ints, as far as I can see. So I would expect that you can just send two
>>>>>>>>>>>>>>>>>>>>>>>> separate ints and Csound would understand it (first the dimension, then the size). This is
>>>>>>>>>>>>>>>>>>>>>>>> what OSCsend2 (& OSCsend) does. Not quite sure what might be going on at your end.
>>>>>>>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> On 5 Apr 2017, at 17:44, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Well I'm doing it in C++ with oscpack and for me it works. Now, I don't
>>>>>>>>>>>>>>>>>>>>>>>>> know much about python for example, but if you are using a python module
>>>>>>>>>>>>>>>>>>>>>>>>> for handling the OSC part of your program, is it possible to construct
>>>>>>>>>>>>>>>>>>>>>>>>> the array to be sent as two ints and the rest as doubles?
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> I'm asking from complete ignorance, Victor. It just seemed odd to
>>>>>>>>>>>>>>>>>>>>>>>>> (instead of passing my entire vector in C++) have to do something like this:
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> unsigned long ui = qvlist.size();
>>>>>>>>>>>>>>>>>>>>>>>>> ui <<= 32; ui |= 1;
>>>>>>>>>>>>>>>>>>>>>>>>> vec.push_back (*(double*)&ui);
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> On 05/04/17 13:30, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> I have implemented the array, audio and function table as per OSCsend/OSClisten. As far as I can see from the code, the blob is as you
>>>>>>>>>>>>>>>>>>>>>>>>>> describe, all data being sent in the native endianess (little endian for i386/x86_64). It could be that the OSC lib is expecting the data
>>>>>>>>>>>>>>>>>>>>>>>>>> in big-endian ints, 4 bytes at a time. As far as I understand, the OSC should not impose any particular interpretation to the blob,
>>>>>>>>>>>>>>>>>>>>>>>>>> but just take it as a string of bytes.
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 5 Apr 2017, at 17:03, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> I'll try it in a few moments. Are you going to replace OSClisten too? If
>>>>>>>>>>>>>>>>>>>>>>>>>>> you do, please beware that right now receiving an array in Csound
>>>>>>>>>>>>>>>>>>>>>>>>>>> expects the structure [dimensions(int); size(int); values(double)...]. I
>>>>>>>>>>>>>>>>>>>>>>>>>>> had to bitshift and cast two ints as a double in order to make that work
>>>>>>>>>>>>>>>>>>>>>>>>>>> from a third-party OSC library outside Csound. It didn't seem right and
>>>>>>>>>>>>>>>>>>>>>>>>>>> I don't think it's possible in every programming language.
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> Cheers.
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 05/04/17 08:30, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Following our conclusion that liblo seems to be overly heavy weight for OSC sending, I have
>>>>>>>>>>>>>>>>>>>>>>>>>>>> implemented an alternative version that uses UDP sockets directly. It is currently called
>>>>>>>>>>>>>>>>>>>>>>>>>>>> OSCsend2 and the interface is exactly the same to OSCsend. In our tests, it appears to
>>>>>>>>>>>>>>>>>>>>>>>>>>>> do the job, but have not tested it extensively.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> It has been suggested to remove OSCsend and replace it with OSCsend2, so I would
>>>>>>>>>>>>>>>>>>>>>>>>>>>> like to check if OSCsend users could test OSCsend2 and let us know if there are differences
>>>>>>>>>>>>>>>>>>>>>>>>>>>> and whether it works OK for you. We would also then like to know whether having
>>>>>>>>>>>>>>>>>>>>>>>>>>>> OSCsend2 alongside OSCsend is your preference, or whether we should just replace it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>> Csound mailing list
>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>  https://github.com/csound/csound/issues
>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>> Csound mailing list
>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>> Send bugs reports to
>>>>>>>>>>  https://github.com/csound/csound/issues
>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>> Csound mailing list
>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>> Send bugs reports to
>>>>>>>>>   https://github.com/csound/csound/issues
>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>> Csound mailing list
>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>> Send bugs reports to
>>>>>>>>    https://github.com/csound/csound/issues
>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>> Csound mailing list
>>>>>>> Csound@listserv.heanet.ie
>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>> Send bugs reports to
>>>>>>>     https://github.com/csound/csound/issues
>>>>>>> Discussions of bugs and features can be posted here
>>>>>> Csound mailing list
>>>>>> Csound@listserv.heanet.ie
>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>> Send bugs reports to
>>>>>>     https://github.com/csound/csound/issues
>>>>>> Discussions of bugs and features can be posted here
>>>>>> 
>>>>>> 
>>>>> Csound mailing list
>>>>> Csound@listserv.heanet.ie
>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>> Send bugs reports to
>>>>>      https://github.com/csound/csound/issues
>>>>> Discussions of bugs and features can be posted here
>>>> Csound mailing list
>>>> Csound@listserv.heanet.ie
>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>> Send bugs reports to
>>>>       https://github.com/csound/csound/issues
>>>> Discussions of bugs and features can be posted here
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>       https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>> 
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>        https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
> 
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here


Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I don't understand why the code for lenarray doesn't work. The following should give you the size of the first dimension instead of the number of dimensions when opt=1, right?

p->tab->sizes[opt-1];

For multidimensional arrays lenarray:k(kArr, 1) and lenarray:k(kArr) are
the ones that don't output the right thing. They give you the number of
dimensions instead of the size of the 1st column.

On 07/04/17 17:33, Victor Lazzarini wrote:

I think it might be something to do with lenarray rather than this opcode. Try to
access the extra members and you will see that they are there.
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

On 7 Apr 2017, at 21:24, Guillermo Senna <gsenna@GMAIL.COM> wrote:

Yes, this one works fine. Although I tried growing the sending array
(1D) to 8 elements and at the receiving end the following sentence still
equals 4.

lenarray:i(kArr, 0) * lenarray:i(kArr)

Then I tried sending a 2D array (2 rows; 4 columns) but that doesn't
work as it doesn't receive [0][3] and [1][3]. I mean it's fine with me
as I don't need that feature. But maybe there should be a warning in the
future new man page.


On 07/04/17 16:57, Victor Lazzarini wrote:

Here’s the code. Instrument 1 has a 4-element array and sends it over OSC to instrument 2.
This one has a 2-dim array with 2 rows 1 column (2 elements). When the array is received,
the columns grow to accommodate 2 extra numbers, turning this into a 2 x 2 matrix.

Note that if I don’t protect the printf call with an if …then, the first time the instrument
is run wil give the index out of range message, because the message hasn’t been
received yet. Once it is, the array grows. The rows never grow, only the columns (by design,
since we have to choose one or the other).

giosc OSCinit 7770

instr	1
kwhen  init 0
kmetro metro 1
kwhen += kmetro
kArr[] init 4
kArr[0] = kwhen
kArr[1] = kwhen+1
kArr[2] = kwhen+2
kArr[3] = kwhen+3
OSCsend2 kwhen, "127.0.0.1",7770, "/foo/bar", "D",kArr
endin

instr 2
ktrig init 1
kArr[][] init 2,1
top:
ka OSClisten giosc, "/foo/bar","D", kArr
if ka > 0 then
printf "%d %d \n%d %d\n", ka*ktrig,
    kArr[0][0], kArr[0][1], 
    kArr[1][0], kArr[1][1]
ktrig += 1     
endif
if ka > 0 kgoto top
endin
schedule(2,0,10)
schedule(1,0,10)


========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

On 7 Apr 2017, at 19:40, Victor Lazzarini <Victor.Lazzarini@nuim.ie> wrote:

I tested here with a 2d array, with size 1 on each dimension, then passed an array with 4  numbers over OSC and dim 1 (number of columns) grew to accommodate it. I am away from the computer but when I have the chance I will post a test CSD.

Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy
Maynooth University
Ireland

On 7 Apr 2017, at 19:27, Guillermo Senna <gsenna@GMAIL.COM> wrote:

I'm getting the same thing, Victor.  Could you try the test files I'm
using? Maybe I'm expecting something that's not even possible.

On 07/04/17 05:00, Victor Lazzarini wrote:
I mean, not the higher ones!
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

On 7 Apr 2017, at 08:58, Victor Lazzarini <Victor.Lazzarini@NUIM.IE> wrote:

Ok, I had things back to front. Now it should work as I planned. The first dimension of the array changes,
not the lower ones. By first dimension I mean the columns in a row-column, ie. counting in the order in which the
indexes appear from right to left.
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

On 7 Apr 2017, at 08:02, Victor Lazzarini <Victor.Lazzarini@nuim.ie> wrote:

yes, I think I am mixing up dimension sizes, I will look. In any case, I will only be able to make one of the dimensions grow (as I can't guess how the matrix/cube/etc grows), whilst keeping the others fixed.

Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy
Maynooth University
Ireland

On 7 Apr 2017, at 07:40, Guillermo Senna <gsenna@GMAIL.COM> wrote:

If I send a unidimensional array (from inside or outside Csound) it does
grow organically!

On 07/04/17 02:39, Victor Lazzarini wrote:
It should be fixed now. The array was growing but I forgot to update the sizes.
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

On 7 Apr 2017, at 06:16, Victor Lazzarini <Victor.Lazzarini@nuim.ie> wrote:

That shouldn't happen, the array should grow. I'll have a look and fix it.

Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy
Maynooth University
Ireland

On 7 Apr 2017, at 04:30, Guillermo Senna <gsenna@GMAIL.COM> wrote:

I tested the new specifier from outside Csound. Now I understand what
you mean Victor. The good thing is that it forces you to choose a common
size between sender and receiver in advance and that prevents you from
getting "osc::OutOfBufferMemoryException" while sending exceedingly
large vectors. The bad thing is the need to process the received array
and look for a delimiter while sending variable-sized arrays like I'm
doing. Or maybe I can just send the size before through "/kArrSize" or
something like that.

Just for the record, with the "A" specifier you can do "kArr[] init 1"
and the array will still grow and shrink dynamically according to
dimensions/sizes received. That is very convenient. With the "D"
specifier you get "Array index 2 out of range (0,0) for dimension 1".

I've to think now how to effectively process the received the array, but
I think you saved me from a difficult-to-diagnose bug that I'd probably
have encountered in the future because of the UDP protocol.

I'll test OSCsend2 now. Cheers.

On 06/04/17 18:33, Victor Lazzarini wrote:
Say you send 10 elements.

You can interpret this as

[1,2,3,4,5,6,7,8,9,10]

or

[1,2]
[3,4]
[5,6]
[7,8]

or

[1,2,3,4,5]
[6,7,8,9,10]

or

[1,2,3]
[4,5,6]
[7,8,9]
[10,0,0]

etc

Whatever you do, if there isn’t enough size, the array grows dynamically. In the last
example there was more than enough size, but we only copied  the 10 numbers
we got.

I have added this type to OSClisten  and OSCsend2. 

========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

On 6 Apr 2017, at 22:20, Guillermo Senna <gsenna@GMAIL.COM> wrote:

Oh, I see. And in the 2D version, if I send a single blob/array with:

10 elements -> they all end up in dimension no. 1

30 elements -> they'd go 16-14

40 elements -> 16-24

Or is it going to be an error not to match the dimensions/sizes?

On 06/04/17 18:10, Victor Lazzarini wrote:
No, I mean

kArr[][] init 2, 16
kk1  OSClisten gihandle, "/multiArr", "D", kArr

or

kArr[] init 32
kk1  OSClisten gihandle, "/multiArr", "D", kArr

both working, the choice is yours


========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

On 6 Apr 2017, at 21:46, Guillermo Senna <gsenna@GMAIL.COM> wrote:

I'm not so sure I follow you with that last sentence. Do you mean
something like this could be possible?

kArr[][] init 2, 16
kk1  OSClisten gihandle, "/multiArr", "DD", kArr[0], kArr[1]

On 06/04/17 17:36, Victor Lazzarini wrote:
yes, same thing from the user perspective. Except that you can define how many dimensions you want
to hold the data in.
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

On 6 Apr 2017, at 21:33, Guillermo Senna <gsenna@GMAIL.COM> wrote:

I like that. Non of those characters are really part of the OSC
specification, so why not?

But with this approach you would still use a Csound array as xdata1 in
OSClisten, right?

On 06/04/17 17:16, Victor Lazzarini wrote:
We could put in a different type name for non-descript double-format data sequence (e.g. 2), for instance
call it “D”.
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

On 6 Apr 2017, at 21:04, Guillermo Senna <gsenna@GMAIL.COM> wrote:

I've not considered number 2 before. How about adding an opcode later
for joining 2d arrays into a single multidimensional? Would it be to
difficult/inefficient to do that considering that in the end it's all
about pointers?

I don't want to change and break it for others already using the current
structure.

On 05/04/17 18:12, Victor Lazzarini wrote:
I see what you mean. It’s possible to change it, there are two options:

1) encode everything with doubles
2) leave dim and size. The size of the blob is always there before the
data, so we can just use that. It will be then up to the user to interpret
the data as a 1,2,3 ,… dimensional array. The data is always stored
as a flat vector (e.g. row-column for 2-d).

if people want it changed, I can do it.
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

On 5 Apr 2017, at 18:24, Guillermo Senna <gsenna@GMAIL.COM> wrote:

My reasoning is that in the different programming languages you'd use a
library/module for handling the OSC part and that would in turn have
some abstraction for sending entire arrays as blobs. Now, Csound
requests for two 32-bit ints and then the rest 64-bits doubles. Is that
always possible to control in the higher-level languages?

Initially what I'd have thought is that I could build an array with all
doubles and Csound would internally truncate the first two values and
cast them into ints.

But if it's working for everyone right now nothing should be changed!

On 05/04/17 14:04, Victor Lazzarini wrote:
Well, Csound reads two ints, as far as I can see. So I would expect that you can just send two
separate ints and Csound would understand it (first the dimension, then the size). This is
what OSCsend2 (& OSCsend) does. Not quite sure what might be going on at your end.
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

On 5 Apr 2017, at 17:44, Guillermo Senna <gsenna@GMAIL.COM> wrote:

Well I'm doing it in C++ with oscpack and for me it works. Now, I don't
know much about python for example, but if you are using a python module
for handling the OSC part of your program, is it possible to construct
the array to be sent as two ints and the rest as doubles?

I'm asking from complete ignorance, Victor. It just seemed odd to
(instead of passing my entire vector in C++) have to do something like this:

unsigned long ui = qvlist.size();
ui <<= 32; ui |= 1;
vec.push_back (*(double*)&ui);

On 05/04/17 13:30, Victor Lazzarini wrote:
I have implemented the array, audio and function table as per OSCsend/OSClisten. As far as I can see from the code, the blob is as you
describe, all data being sent in the native endianess (little endian for i386/x86_64). It could be that the OSC lib is expecting the data
in big-endian ints, 4 bytes at a time. As far as I understand, the OSC should not impose any particular interpretation to the blob,
but just take it as a string of bytes.

========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

On 5 Apr 2017, at 17:03, Guillermo Senna <gsenna@GMAIL.COM> wrote:

I'll try it in a few moments. Are you going to replace OSClisten too? If
you do, please beware that right now receiving an array in Csound
expects the structure [dimensions(int); size(int); values(double)...]. I
had to bitshift and cast two ints as a double in order to make that work
from a third-party OSC library outside Csound. It didn't seem right and
I don't think it's possible in every programming language.

Cheers.

On 05/04/17 08:30, Victor Lazzarini wrote:
Following our conclusion that liblo seems to be overly heavy weight for OSC sending, I have
implemented an alternative version that uses UDP sockets directly. It is currently called
OSCsend2 and the interface is exactly the same to OSCsend. In our tests, it appears to
do the job, but have not tested it extensively.

It has been suggested to remove OSCsend and replace it with OSCsend2, so I would
like to check if OSCsend users could test OSCsend2 and let us know if there are differences
and whether it works OK for you. We would also then like to know whether having
OSCsend2 alongside OSCsend is your preference, or whether we should just replace it.

========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
 https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
  https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
  https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
   https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
    https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
     https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
     https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here
<OSCreceive.csd>
<OSCsend.csd>

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
      https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
       https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
       https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

How silly of me. I now understand what's happening. There are two
dimensions and also the first dimension has size=2.


On 07/04/17 17:56, Victor Lazzarini wrote:
> Rows are 1 and columns 2 in this case. The code I fixed should work now
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952 
>
>> On 7 Apr 2017, at 21:50, Guillermo Senna  wrote:
>>
>> For multidimensional arrays lenarray:k(kArr, 1) and lenarray:k(kArr) are
>> the ones that don't output the right thing. They give you the number of
>> dimensions instead of the size of the 1st column.
>>
>> On 07/04/17 17:33, Victor Lazzarini wrote:
>>> I think it might be something to do with lenarray rather than this opcode. Try to
>>> access the extra members and you will see that they are there.
>>> ========================
>>> Prof. Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy,
>>> Maynooth University,
>>> Maynooth, Co Kildare, Ireland
>>> Tel: 00 353 7086936
>>> Fax: 00 353 1 7086952 
>>>
>>>> On 7 Apr 2017, at 21:24, Guillermo Senna  wrote:
>>>>
>>>> Yes, this one works fine. Although I tried growing the sending array
>>>> (1D) to 8 elements and at the receiving end the following sentence still
>>>> equals 4.
>>>>
>>>> lenarray:i(kArr, 0) * lenarray:i(kArr)
>>>>
>>>> Then I tried sending a 2D array (2 rows; 4 columns) but that doesn't
>>>> work as it doesn't receive [0][3] and [1][3]. I mean it's fine with me
>>>> as I don't need that feature. But maybe there should be a warning in the
>>>> future new man page.
>>>>
>>>>
>>>> On 07/04/17 16:57, Victor Lazzarini wrote:
>>>>> Here’s the code. Instrument 1 has a 4-element array and sends it over OSC to instrument 2.
>>>>> This one has a 2-dim array with 2 rows 1 column (2 elements). When the array is received,
>>>>> the columns grow to accommodate 2 extra numbers, turning this into a 2 x 2 matrix.
>>>>>
>>>>> Note that if I don’t protect the printf call with an if …then, the first time the instrument
>>>>> is run wil give the index out of range message, because the message hasn’t been
>>>>> received yet. Once it is, the array grows. The rows never grow, only the columns (by design,
>>>>> since we have to choose one or the other).
>>>>>
>>>>> giosc OSCinit 7770
>>>>>
>>>>> instr	1
>>>>> kwhen  init 0
>>>>> kmetro metro 1
>>>>> kwhen += kmetro
>>>>> kArr[] init 4
>>>>> kArr[0] = kwhen
>>>>> kArr[1] = kwhen+1
>>>>> kArr[2] = kwhen+2
>>>>> kArr[3] = kwhen+3
>>>>> OSCsend2 kwhen, "127.0.0.1",7770, "/foo/bar", "D",kArr
>>>>> endin
>>>>>
>>>>> instr 2
>>>>> ktrig init 1
>>>>> kArr[][] init 2,1
>>>>> top:
>>>>> ka OSClisten giosc, "/foo/bar","D", kArr
>>>>> if ka > 0 then
>>>>> printf "%d %d \n%d %d\n", ka*ktrig,
>>>>>    kArr[0][0], kArr[0][1], 
>>>>>    kArr[1][0], kArr[1][1]
>>>>> ktrig += 1     
>>>>> endif
>>>>> if ka > 0 kgoto top
>>>>> endin
>>>>> schedule(2,0,10)
>>>>> schedule(1,0,10)
>>>>>
>>>>>
>>>>> ========================
>>>>> Prof. Victor Lazzarini
>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>> Maynooth University,
>>>>> Maynooth, Co Kildare, Ireland
>>>>> Tel: 00 353 7086936
>>>>> Fax: 00 353 1 7086952 
>>>>>
>>>>>> On 7 Apr 2017, at 19:40, Victor Lazzarini  wrote:
>>>>>>
>>>>>> I tested here with a 2d array, with size 1 on each dimension, then passed an array with 4  numbers over OSC and dim 1 (number of columns) grew to accommodate it. I am away from the computer but when I have the chance I will post a test CSD.
>>>>>>
>>>>>> Victor Lazzarini
>>>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>>>> Maynooth University
>>>>>> Ireland
>>>>>>
>>>>>>> On 7 Apr 2017, at 19:27, Guillermo Senna  wrote:
>>>>>>>
>>>>>>> I'm getting the same thing, Victor.  Could you try the test files I'm
>>>>>>> using? Maybe I'm expecting something that's not even possible.
>>>>>>>
>>>>>>>
>>>>>>>> On 07/04/17 05:00, Victor Lazzarini wrote:
>>>>>>>> I mean, not the higher ones!
>>>>>>>> ========================
>>>>>>>> Prof. Victor Lazzarini
>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>> Maynooth University,
>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>> Tel: 00 353 7086936
>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>
>>>>>>>>> On 7 Apr 2017, at 08:58, Victor Lazzarini  wrote:
>>>>>>>>>
>>>>>>>>> Ok, I had things back to front. Now it should work as I planned. The first dimension of the array changes,
>>>>>>>>> not the lower ones. By first dimension I mean the columns in a row-column, ie. counting in the order in which the
>>>>>>>>> indexes appear from right to left.
>>>>>>>>> ========================
>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>> Maynooth University,
>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>
>>>>>>>>>> On 7 Apr 2017, at 08:02, Victor Lazzarini  wrote:
>>>>>>>>>>
>>>>>>>>>> yes, I think I am mixing up dimension sizes, I will look. In any case, I will only be able to make one of the dimensions grow (as I can't guess how the matrix/cube/etc grows), whilst keeping the others fixed.
>>>>>>>>>>
>>>>>>>>>> Victor Lazzarini
>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>>>>>>>> Maynooth University
>>>>>>>>>> Ireland
>>>>>>>>>>
>>>>>>>>>>> On 7 Apr 2017, at 07:40, Guillermo Senna  wrote:
>>>>>>>>>>>
>>>>>>>>>>> If I send a unidimensional array (from inside or outside Csound) it does
>>>>>>>>>>> grow organically!
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> On 07/04/17 02:39, Victor Lazzarini wrote:
>>>>>>>>>>>> It should be fixed now. The array was growing but I forgot to update the sizes.
>>>>>>>>>>>> ========================
>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>
>>>>>>>>>>>>> On 7 Apr 2017, at 06:16, Victor Lazzarini  wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> That shouldn't happen, the array should grow. I'll have a look and fix it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Victor Lazzarini
>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>>>>>>>>>>> Maynooth University
>>>>>>>>>>>>> Ireland
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 7 Apr 2017, at 04:30, Guillermo Senna  wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I tested the new specifier from outside Csound. Now I understand what
>>>>>>>>>>>>>> you mean Victor. The good thing is that it forces you to choose a common
>>>>>>>>>>>>>> size between sender and receiver in advance and that prevents you from
>>>>>>>>>>>>>> getting "osc::OutOfBufferMemoryException" while sending exceedingly
>>>>>>>>>>>>>> large vectors. The bad thing is the need to process the received array
>>>>>>>>>>>>>> and look for a delimiter while sending variable-sized arrays like I'm
>>>>>>>>>>>>>> doing. Or maybe I can just send the size before through "/kArrSize" or
>>>>>>>>>>>>>> something like that.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Just for the record, with the "A" specifier you can do "kArr[] init 1"
>>>>>>>>>>>>>> and the array will still grow and shrink dynamically according to
>>>>>>>>>>>>>> dimensions/sizes received. That is very convenient. With the "D"
>>>>>>>>>>>>>> specifier you get "Array index 2 out of range (0,0) for dimension 1".
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I've to think now how to effectively process the received the array, but
>>>>>>>>>>>>>> I think you saved me from a difficult-to-diagnose bug that I'd probably
>>>>>>>>>>>>>> have encountered in the future because of the UDP protocol.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'll test OSCsend2 now. Cheers.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 06/04/17 18:33, Victor Lazzarini wrote:
>>>>>>>>>>>>>>> Say you send 10 elements.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You can interpret this as
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [1,2,3,4,5,6,7,8,9,10]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [1,2]
>>>>>>>>>>>>>>> [3,4]
>>>>>>>>>>>>>>> [5,6]
>>>>>>>>>>>>>>> [7,8]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [1,2,3,4,5]
>>>>>>>>>>>>>>> [6,7,8,9,10]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [1,2,3]
>>>>>>>>>>>>>>> [4,5,6]
>>>>>>>>>>>>>>> [7,8,9]
>>>>>>>>>>>>>>> [10,0,0]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> etc
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Whatever you do, if there isn’t enough size, the array grows dynamically. In the last
>>>>>>>>>>>>>>> example there was more than enough size, but we only copied  the 10 numbers
>>>>>>>>>>>>>>> we got.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I have added this type to OSClisten  and OSCsend2. 
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 6 Apr 2017, at 22:20, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Oh, I see. And in the 2D version, if I send a single blob/array with:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 10 elements -> they all end up in dimension no. 1
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 30 elements -> they'd go 16-14
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 40 elements -> 16-24
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Or is it going to be an error not to match the dimensions/sizes?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 06/04/17 18:10, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>> No, I mean
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> kArr[][] init 2, 16
>>>>>>>>>>>>>>>>> kk1  OSClisten gihandle, "/multiArr", "D", kArr
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> kArr[] init 32
>>>>>>>>>>>>>>>>> kk1  OSClisten gihandle, "/multiArr", "D", kArr
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> both working, the choice is yours
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 6 Apr 2017, at 21:46, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I'm not so sure I follow you with that last sentence. Do you mean
>>>>>>>>>>>>>>>>>> something like this could be possible?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> kArr[][] init 2, 16
>>>>>>>>>>>>>>>>>> kk1  OSClisten gihandle, "/multiArr", "DD", kArr[0], kArr[1]
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 06/04/17 17:36, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>>> yes, same thing from the user perspective. Except that you can define how many dimensions you want
>>>>>>>>>>>>>>>>>>> to hold the data in.
>>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 6 Apr 2017, at 21:33, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I like that. Non of those characters are really part of the OSC
>>>>>>>>>>>>>>>>>>>> specification, so why not?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> But with this approach you would still use a Csound array as xdata1 in
>>>>>>>>>>>>>>>>>>>> OSClisten, right?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 06/04/17 17:16, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>>>>> We could put in a different type name for non-descript double-format data sequence (e.g. 2), for instance
>>>>>>>>>>>>>>>>>>>>> call it “D”.
>>>>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 6 Apr 2017, at 21:04, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I've not considered number 2 before. How about adding an opcode later
>>>>>>>>>>>>>>>>>>>>>> for joining 2d arrays into a single multidimensional? Would it be to
>>>>>>>>>>>>>>>>>>>>>> difficult/inefficient to do that considering that in the end it's all
>>>>>>>>>>>>>>>>>>>>>> about pointers?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I don't want to change and break it for others already using the current
>>>>>>>>>>>>>>>>>>>>>> structure.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 05/04/17 18:12, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>>>>>>> I see what you mean. It’s possible to change it, there are two options:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 1) encode everything with doubles
>>>>>>>>>>>>>>>>>>>>>>> 2) leave dim and size. The size of the blob is always there before the
>>>>>>>>>>>>>>>>>>>>>>> data, so we can just use that. It will be then up to the user to interpret
>>>>>>>>>>>>>>>>>>>>>>> the data as a 1,2,3 ,… dimensional array. The data is always stored
>>>>>>>>>>>>>>>>>>>>>>> as a flat vector (e.g. row-column for 2-d).
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> if people want it changed, I can do it.
>>>>>>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On 5 Apr 2017, at 18:24, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> My reasoning is that in the different programming languages you'd use a
>>>>>>>>>>>>>>>>>>>>>>>> library/module for handling the OSC part and that would in turn have
>>>>>>>>>>>>>>>>>>>>>>>> some abstraction for sending entire arrays as blobs. Now, Csound
>>>>>>>>>>>>>>>>>>>>>>>> requests for two 32-bit ints and then the rest 64-bits doubles. Is that
>>>>>>>>>>>>>>>>>>>>>>>> always possible to control in the higher-level languages?
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Initially what I'd have thought is that I could build an array with all
>>>>>>>>>>>>>>>>>>>>>>>> doubles and Csound would internally truncate the first two values and
>>>>>>>>>>>>>>>>>>>>>>>> cast them into ints.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> But if it's working for everyone right now nothing should be changed!
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On 05/04/17 14:04, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> Well, Csound reads two ints, as far as I can see. So I would expect that you can just send two
>>>>>>>>>>>>>>>>>>>>>>>>> separate ints and Csound would understand it (first the dimension, then the size). This is
>>>>>>>>>>>>>>>>>>>>>>>>> what OSCsend2 (& OSCsend) does. Not quite sure what might be going on at your end.
>>>>>>>>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> On 5 Apr 2017, at 17:44, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Well I'm doing it in C++ with oscpack and for me it works. Now, I don't
>>>>>>>>>>>>>>>>>>>>>>>>>> know much about python for example, but if you are using a python module
>>>>>>>>>>>>>>>>>>>>>>>>>> for handling the OSC part of your program, is it possible to construct
>>>>>>>>>>>>>>>>>>>>>>>>>> the array to be sent as two ints and the rest as doubles?
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> I'm asking from complete ignorance, Victor. It just seemed odd to
>>>>>>>>>>>>>>>>>>>>>>>>>> (instead of passing my entire vector in C++) have to do something like this:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> unsigned long ui = qvlist.size();
>>>>>>>>>>>>>>>>>>>>>>>>>> ui <<= 32; ui |= 1;
>>>>>>>>>>>>>>>>>>>>>>>>>> vec.push_back (*(double*)&ui);
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 05/04/17 13:30, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> I have implemented the array, audio and function table as per OSCsend/OSClisten. As far as I can see from the code, the blob is as you
>>>>>>>>>>>>>>>>>>>>>>>>>>> describe, all data being sent in the native endianess (little endian for i386/x86_64). It could be that the OSC lib is expecting the data
>>>>>>>>>>>>>>>>>>>>>>>>>>> in big-endian ints, 4 bytes at a time. As far as I understand, the OSC should not impose any particular interpretation to the blob,
>>>>>>>>>>>>>>>>>>>>>>>>>>> but just take it as a string of bytes.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 5 Apr 2017, at 17:03, Guillermo Senna  wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> I'll try it in a few moments. Are you going to replace OSClisten too? If
>>>>>>>>>>>>>>>>>>>>>>>>>>>> you do, please beware that right now receiving an array in Csound
>>>>>>>>>>>>>>>>>>>>>>>>>>>> expects the structure [dimensions(int); size(int); values(double)...]. I
>>>>>>>>>>>>>>>>>>>>>>>>>>>> had to bitshift and cast two ints as a double in order to make that work
>>>>>>>>>>>>>>>>>>>>>>>>>>>> from a third-party OSC library outside Csound. It didn't seem right and
>>>>>>>>>>>>>>>>>>>>>>>>>>>> I don't think it's possible in every programming language.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Cheers.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 05/04/17 08:30, Victor Lazzarini wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Following our conclusion that liblo seems to be overly heavy weight for OSC sending, I have
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> implemented an alternative version that uses UDP sockets directly. It is currently called
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> OSCsend2 and the interface is exactly the same to OSCsend. In our tests, it appears to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> do the job, but have not tested it extensively.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It has been suggested to remove OSCsend and replace it with OSCsend2, so I would
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> like to check if OSCsend users could test OSCsend2 and let us know if there are differences
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and whether it works OK for you. We would also then like to know whether having
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> OSCsend2 alongside OSCsend is your preference, or whether we should just replace it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>> https://github.com/csound/csound/issues
>>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>>> Csound mailing list
>>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>>  https://github.com/csound/csound/issues
>>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>>> Csound mailing list
>>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>>> Send bugs reports to
>>>>>>>>>>>  https://github.com/csound/csound/issues
>>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>>> Csound mailing list
>>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>>> Send bugs reports to
>>>>>>>>>>   https://github.com/csound/csound/issues
>>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>>> Csound mailing list
>>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>>> Send bugs reports to
>>>>>>>>>    https://github.com/csound/csound/issues
>>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>> Csound mailing list
>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>> Send bugs reports to
>>>>>>>>     https://github.com/csound/csound/issues
>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>> Csound mailing list
>>>>>>> Csound@listserv.heanet.ie
>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>> Send bugs reports to
>>>>>>>     https://github.com/csound/csound/issues
>>>>>>> Discussions of bugs and features can be posted here
>>>>>>> 
>>>>>>> 
>>>>>> Csound mailing list
>>>>>> Csound@listserv.heanet.ie
>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>> Send bugs reports to
>>>>>>      https://github.com/csound/csound/issues
>>>>>> Discussions of bugs and features can be posted here
>>>>> Csound mailing list
>>>>> Csound@listserv.heanet.ie
>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>> Send bugs reports to
>>>>>       https://github.com/csound/csound/issues
>>>>> Discussions of bugs and features can be posted here
>>>> Csound mailing list
>>>> Csound@listserv.heanet.ie
>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>> Send bugs reports to
>>>>       https://github.com/csound/csound/issues
>>>> Discussions of bugs and features can be posted here
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>        https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>        https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here