Since SourceForge is being incredibly slow today, I'd like to point out 
the potential importance of having multiple instances of an OSCinit 
opcode (multiple open ports) per instance of Csound.

As it is, it's not too big of a deal to use multiple instances of 
Csound to have multiple OSC ports open, but of course this is quite an 
inelegant solution. Surely if there was ever a plan to have Csound 
communicate with Common Music, you would require more than just one 
port of data (maybe not?).

I think that just the possibility of using OSC with Csound creates 
immense realtime performance possibilities and also we open up this 
whole can of worms about Csound over a network(!!). Of course I 
understand if it is hard to implement as you would probably have to 
check which ports were open before allowing an instance on that port to 
prevent invalid access or a segmentation fault or something ugly like 
that.

What if any musical implication do you guys see in OSC port 
instantiation per instance of Csound?


-David

Can you explain further ?  As far as I know there is no problem with
multiple ports and multiple calls to OSCinit.  Did I get it wrong?
Certainly that was the intention.
==John ffitch


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Oct 11, 2005, at 1:03 PM, jpff@codemist.co.uk wrote:

> Can you explain further ?

Of course. What follows is an example of the OSC opcodes. I find that 
running the attached instrument as-is works good. To run this .csd 
file, use the -Lstdin commandline flag and type "i1 0 1000" and for 
every "i3 0 1" you should get a random number at /foo/bar.

If you uncomment all the comments, Csound wouldn't even start for me 
erroring out with "OSC: failed to allocate globals". A verbose log of 
the commandline follows the Csound example.





sr	=	44100
kr	=	441
ksmps	=	100
nchnls	=	2
	OSCinit	4200
;	OSCinit	4201

/*--- ---*/

		instr	1	;  make sure data gets to Csound

kf1 init 0
kf2 init 0

kk  OSClisten "/foo/bar", "ff", kf1, kf2

if kk =0 goto ex

	printk2 kf1
	printk2 kf2

ex:
		endin

/*---

		instr	2	;  the test - won't listen to /foo/bar or send

kf1 init 0
kf2 init 0

kk  OSClisten "/foo/bar", "ff", kf1, kf2

if kk =0 goto ex

	OSCsend	1, "localhost", 4201, "/testdata/recv", "ffi", kf1, kf2, 420

ex:
		endin

---*/

		instr	3	;  send

;kf1 init 0
;kf2 init 0
;kf3 init 0

irand	random	-127.0, 127.0

	OSCsend	1, "localhost", 4200, "/foo/bar", "ff", irand, irand
;kk	OSClisten	"/testdata/recv", "ffs", kf1, kf2, kf3

;if kk =0 goto ex
	
;	printk2 kf1
;	printk2 kf2
;	printk2 kf3

;ex:
		endin

/*--- ---*/


f0	8888




[dhcp31-9-106:~/CVS/csound5] daveakba% ./csound -odac:1 -idevaudio:1 
-+noninterleaved=1 -+rtaudio=CoreAudio -Lstdin ~/Desktop/oscTest.csd
Localisation of messages is disabled, using default language.
time resolution is 1000.000 ns
PortMIDI real time MIDI plugin for Csound
CoreAudio real-time audio module for Csound
by Victor Lazzarini
PortAudio real-time audio module for Csound
0dBFS level = 32768.0
Csound version 5.00.0 beta (double samples) Oct 11 2005
libsndfile-1.0.11
UnifiedCSD:  /Users/daveakbari/Desktop/oscTest.csd
STARTING FILE
Creating orchestra
Creating /var/tmp/tmp.orc (0xa000a928)
Creating score
orchname:  /var/tmp/tmp.orc
scorename: /var/tmp/tmp.sco
rtaudio: CoreAudio module enabled
rtmidi: PortMIDI module enabled
****OSC: liblo started****
orch compiler:
65 lines read
         instr   1
         instr   3
Elapsed time at end of orchestra compile: real: 0.032s, CPU: 0.010s
sorting score ...
         ... done
Elapsed time at end of score sort: real: 0.193s, CPU: 0.040s
Csound version 5.00.0 beta (double samples) Oct 11 2005
0dBFS level = 32768.0
OSC listener started
OSC: failed to allocate globals
inactive allocs returned to freespace
end of score.              overall amps:      0.0      0.0
            overall samples out of range:        0        0
0 errors in performance


-David



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

David Akbari wrote:

> Of course. What follows is an example of the OSC opcodes. I find that 
> running the attached instrument as-is works good. To run this .csd file, 
> use the -Lstdin commandline flag and type "i1 0 1000" and for every "i3 
> 0 1" you should get a random number at /foo/bar.
> 
> If you uncomment all the comments, Csound wouldn't even start for me 
> erroring out with "OSC: failed to allocate globals". A verbose log of 
> the commandline follows the Csound example.

How about using a single port but multiple paths (i.e. not just "/foo/bar") ?
Also, if multiple OSCinit's would indeed work, how is an OSClisten supposed
to know which one of the multiple ports it should use ? Some changes to the
opcode syntax may be needed, including the addition of a new argument to
OSClisten that associates it with a particular OSCinit.

> kk  OSClisten "/foo/bar", "ff", kf1, kf2

Not related to this issue, but I think writing to a 'z' list of input
arguments is dangerous, as it allows for overwriting constants or reserved
variables like nchnls.


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Oct 12, 2005, at 7:38 AM, Istvan Varga wrote:

> How about using a single port but multiple paths (i.e. not just 
> "/foo/bar") ?

This helps a lot for routing a single set of data to multiple locations 
(I had not thought of this in Csound!) but it still does not solve the 
problem of then re-sending the data out on a different port (in a 
single instance of Csound). Currently it is no problem to have multiple 
instances of Csound running each with it's own initialized OSC port.

> Also, if multiple OSCinit's would indeed work, how is an OSClisten 
> supposed
> to know which one of the multiple ports it should use ?

This is an excellent point, perhaps it would require a handler or 
numeric index? Something like strset perhaps?

> Some changes to the
> opcode syntax may be needed, including the addition of a new argument 
> to
> OSClisten that associates it with a particular OSCinit.
>

This extra argument could likely also be a numeric index, reminiscent 
of the ZAK opcodes. It would add, of course as you mentioned, another 
argument and would likely break some existing orchestras but that is 
why at present, we can still label the program as being in beta status 
and render these points moot.


-David



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I think that multiple ports makes sense, and so yes it means that
OSCinit will need to return a value that is used in the listener.
Will look at it today.
==John ffitch


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

David Akbari wrote:

> This helps a lot for routing a single set of data to multiple locations 
> (I had not thought of this in Csound!) but it still does not solve the 
> problem of then re-sending the data out on a different port (in a single 
> instance of Csound).

If you mean one port for input and another for output, then you
do not need two OSCinit calls, as OSCsend does not depend on
OSCinit and takes an explicit port number.


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I have just committed code that allows multiple ports in OSC listeners.
Seems OK.  Otherwise no change.
==John ffitch


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

jpff@codemist.co.uk wrote:

> I have just committed code that allows multiple ports in OSC listeners.
> Seems OK.  Otherwise no change.

By the way, would it be useful to allow for receiving string messages
in S-variables ?


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Oct 13, 2005, at 5:25 AM, Istvan Varga wrote:

> If you mean one port for input and another for output, then you
> do not need two OSCinit calls, as OSCsend does not depend on
> OSCinit and takes an explicit port number.


I was previously unaware of this, and I can see that it works as 
expected... I would've thought you would need to initialize the 
explicit port number first, oh well it seems easier this way anyway. 
Thanks for the clarification!


On Oct 13, 2005, at 8:05 AM, Istvan Varga wrote:

> jpff@codemist.co.uk wrote:
>
>> I have just committed code that allows multiple ports in OSC 
>> listeners.
>> Seems OK.  Otherwise no change.
>
> By the way, would it be useful to allow for receiving string messages
> in S-variables ?
>

I thought initially this was how you did it if you had an "s" character 
in your z-list!! Apparently I was wrong on that but since you reiterate 
the idea I think it's a great one.

Also, what other semantics of the language exist at present to take 
advantage of the other possibilities included in the z-list, like 
char's and booleans?


-David



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

>>>>> "Istvan" == Istvan Varga  writes:

 Istvan> By the way, would it be useful to allow for receiving string messages
 Istvan> in S-variables ?

Sure.  At present no idea who so to do.




==John ffitch


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

PA: v19 (devel)
PM: the latest.

Victor

At 14:50 13/10/2005, you wrote:
>Greetings:
>
>  I'm working on building Cs5 "The Whole Enchilada" on AGNULA/Demudi 1.2.1 
> but I'm hitting the wall with some PortAudio errors during compilation of 
> rtpa.c. Before I send the report I thought I should find out what 
> versions of PA/PM are currently recommended for Cs5.
>
>  I'm using the latest CVS sources. Maybe I should use a tarball instead ?
>
>Best,
>
>dp
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by:
>Power Architecture Resource Center: Free content, downloads, discussions,
>and more. http://solutions.newsforge.com/ibmarch.tmpl
>_______________________________________________
>Csound-devel mailing list
>Csound-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/csound-devel

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth 



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Greetings:

  I'm working on building Cs5 "The Whole Enchilada" on AGNULA/Demudi 
1.2.1 but I'm hitting the wall with some PortAudio errors during 
compilation of rtpa.c. Before I send the report I thought I should find 
out what versions of PA/PM are currently recommended for Cs5.

  I'm using the latest CVS sources. Maybe I should use a tarball instead ?

Best,

dp



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Dave Phillips wrote:

>  I'm working on building Cs5 "The Whole Enchilada" on AGNULA/Demudi 
> 1.2.1 but I'm hitting the wall with some PortAudio errors during 
> compilation of rtpa.c. Before I send the report I thought I should find 
> out what versions of PA/PM are currently recommended for Cs5.
> 
>  I'm using the latest CVS sources. Maybe I should use a tarball instead ?

Unless recent changes to PortAudio introduced the errors, it is most
likely that you have PortAudio v18. Csound requires v19.


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Portaudio v19 -- I am using the version from last November as they still 
have not made it 64bit compatible

Portmidi seems to be from last November as well.  

==John




-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Answering my own query:

  The CVS sources should not be used. The latest V19 tarball works 
perfectly.

Best,

dp



Dave Phillips wrote:

> Greetings:
>
>  I'm working on building Cs5 "The Whole Enchilada" on AGNULA/Demudi 
> 1.2.1 but I'm hitting the wall with some PortAudio errors during 
> compilation of rtpa.c. Before I send the report I thought I should 
> find out what versions of PA/PM are currently recommended for Cs5.
>
>  I'm using the latest CVS sources. Maybe I should use a tarball instead ?
>
> Best,
>
> dp
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Istvan Varga wrote:
>> I have just committed code that allows multiple ports in OSC listeners.
>> Seems OK.  Otherwise no change.
> 
> 
> By the way, would it be useful to allow for receiving string messages
> in S-variables ?
> 

sure it would. actually I see no reason to discard any type of variable..


regards,

Stef


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I am now testing a version of the OSClisten opcode that can receive strings
and use multiple ports. By the way, is it possibly a problem that the license
of liblo is GPL while Csound is LGPL ?


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

>>>>> "Istvan" == Istvan Varga  writes:

 Istvan> I am now testing a version of the OSClisten opcode that can receive strings
 Istvan> and use multiple ports. By the way, is it possibly a problem that the license
 Istvan> of liblo is GPL while Csound is LGPL ?

I raised this with Steve Harris, and he asserts that there is no
problem, citing some rule that one can link a GPL library to as LGPL
program.  I hope I kept the message!

==John ffitch


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I have made changes to OSCinit and OSClisten to allow for using
multiple ports, string data, and safely handle multiple messages in
the same control period by adding a dynamically extended FIFO buffer.
Also made use of mutexes for (hopefully) thread safe communication
between the server thread(s) and any OSClisten opcodes. The changes
did make the code more complex and less efficient, though, so there
is definitely place for optimizations.
The types currently allowed include 32 and 64 bit integers and
floats ('i', 'h', 'f', 'd'), characters ('c'), and strings ('s').
Here is a simple example of receiving data from multiple ports:





giport1 OSCinit 7770
giport2 OSCinit 7771

     instr 2
kf1     init 0
kf2     init 0
Sf3     =  ""
ktrig   init 1
kk      OSClisten   giport1, "/foo/bar", "ifs", kf1, kf2, Sf3
         printf "Port 7770, /foo/bar:  %d, %f, %s\n", kk * ktrig, kf1, kf2, Sf3
kk      OSClisten   giport1, "/foo/blah", "ifs", kf1, kf2, Sf3
         printf "Port 7770, /foo/blah: %d, %f, %s\n", kk * ktrig, kf1, kf2, Sf3
kk      OSClisten   giport2, "/foo/bar", "ifs", kf1, kf2, Sf3
         printf "Port 7771, /foo/bar:  %d, %f, %s\n", kk * ktrig, kf1, kf2, Sf3
ktrig   =  3 - ktrig    ; make sure that it always changes
     endin




i2 0 30
e





-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Oct 14, 2005, at 3:46 PM, Istvan Varga wrote:

> I have made changes to OSCinit and OSClisten to allow for using
> multiple ports, string data, and safely handle multiple messages in
> the same control period by adding a dynamically extended FIFO buffer.
> Also made use of mutexes for (hopefully) thread safe communication
> between the server thread(s) and any OSClisten opcodes. The changes
> did make the code more complex and less efficient, though, so there
> is definitely place for optimizations.
> The types currently allowed include 32 and 64 bit integers and
> floats ('i', 'h', 'f', 'd'), characters ('c'), and strings ('s').

It looks like there has been a vast improvement in the Opcodes/OSC.c 
code. However when trying to compile from fresh CVS, the compiler gives 
this error:

Opcodes/OSC.c: In function `OSC_listdeinit':
Opcodes/OSC.c:578: warning: implicit declaration of function 
`lo_server_thread_del_method'

...

gcc -framework CoreMidi -framework CoreFoundation -framework CoreAudio 
-dynamiclib -o libosc.dylib Opcodes/OSC.os -L. -L. -L/usr/local/lib -L. 
-L. -lsndfile -llo -lpthread
ld: Undefined symbols:
_lo_server_thread_del_method
/usr/bin/libtool: internal link edit command failed
scons: *** [libosc.dylib] Error 1
scons: building terminated because of errors.

...

Investigating the liblo headers further, I could not find the function 
lo_server_thread_del_method. Here is the line in context:

static int OSC_listdeinit(CSOUND *csound, OSCLISTEN *p)
{
    // lines omitted for legibility

     lo_server_thread_del_method(p->port->thread, p->saved_path, 
p->saved_types);

     return OK;
}

Is it possible I am not using the current liblo headers?

Everything else about the build seems OK.


-David

On Oct 14, 2005, at 4:45 PM, David Akbari wrote:

> Is it possible I am not using the current liblo headers?

Yep. Sorry for the hasty posting.


-David

P.S. The OSC opcodes now seem to run excellent on OSX. (Although they 
did before). Has anyone been building OSC for Windows?

I ran the OSC opcodes on Windows before the latest changes.  Will try
to cj=eck again this weekend.
==John ffitch


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

jpff@codemist.co.uk wrote:

> I ran the OSC opcodes on Windows before the latest changes.  Will try
> to cj=eck again this weekend.

Note that a newer version of liblo that has lo_server_thread_del_method()
may be needed.


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

So he added that did he?  I did ask.
==John ffitch
>>>>> "Istvan" == Istvan Varga  writes:

 Istvan> Note that a newer version of liblo that has lo_server_thread_del_method()
 Istvan> may be needed.



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net