Where did it go?
==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@cs.bath.ac.uk wrote:

> Where did it go?

It is in Opcodes/OSC.c.


-------------------------------------------------------
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

Also on the topic of this thread, what are some ways that OSCrecv 
differs from the OSClisten opcode ?

Possibly is it similar to OSCsend where there is explicit port index 
that does not need to be initialized at orchestra compilation time ?

The documentation I found from the list archives says the syntax is 
expected to be :

  kin  OSCrecv     "service" [, iinit, imin, imax]

whereas a ./csound -z1 output from today's (Oct 21 2005) CVS sources 
says the syntax is expected to be :

OSCrecv     (null)      iSo

What is the expected syntax ?

OSCrecv iport, Sdestination, [iscalar-something ??]

Any help appreciated as I'm sure the current state is an improvement 
from the list archive description I found!

Also it may be helpful to append the documentation for OSCrecv at this 
URL :

http://csounds.com/manual/html/OSC.html

Of course I can add this documentation, but I do not wish to undermine 
anyone's development efforts (with the manual especially) !! And on 
that note OSClisten needs to be revised as well as the example 
currently says:

sr = 44100
         ksmps = 100
         nchnls = 2

         OSClisten 7770

         instr   1
           kf1 init 0
           kf2 init 0
           kk  OSClisten "/foo/bar", "ff", kf1, kf2
      if kk =0 goto ex
           printk 0,kf1
           printk 0,kf2
      ex:
         endin

when it should be:

sr	=	44100
ksmps	=	100
nchnls	=	2

giport	OSCinit	7770

	instr	1
	  kf1 init 0
	  kf2 init 0
	  kk OSClisten giport, "/foo/bar", "ff", kf1, kf2
	if kk =0 goto ex
		printk  0,kf1
		printk  0,kf2
	ex:
	endin

note the required port argument to OSCinit and OSClisten that the 
manual does not reflect currently. I find this new functionality to be 
most improved as now it is possible to have multiple listeners in a 
single CSD!

Here's a more involved example which can control a Csound file over 
ethernet with an Oxygen8 keyboard controller. Note this can be used 
with any midi keyboard, you just have to change the send destination 
the Listener is looking at:


sr		=	44100
kr		=	441
ksmps	=	100
nchnls	=	2
	zakinit	2, 16

giport	OSCinit	57120

/*--- ---*/

	opcode  cpsmid, k, k
kmid    xin
#define MIDI2CPS(xmidi) # (440.0*exp(log(2.0)*(($xmidi)-69.0)/12.0)) #
kcps    =       $MIDI2CPS(kmid)
         xout    kcps
                 endop

/*--- ---*/

		instr	1

kbendr	init	0

kmwhl	init	0
kdats	init	0

kpt1	init	0
kpt2	init	0
kpt3	init	0
kpt4	init	0
kpt5	init	0
kpt6	init	0
kpt7	init	0
kpt8	init	0

knum	init	0
kvelo	init	0

kbnd	OSClisten	giport, "/oxygen8/control/bender", "i", kbendr

kcc1	OSClisten	giport, "/oxygen8/control/mwheel", "i", kmwhl
kcc7	OSClisten	giport, "/oxygen8/control/dataslid", "i", kdats

kcc8	OSClisten	giport, "/oxygen8/control/pot1", "i", kpt1
kcc9	OSClisten	giport, "/oxygen8/control/pot2", "i", kpt2
kccA	OSClisten	giport, "/oxygen8/control/pot3", "i", kpt3
kccB	OSClisten	giport, "/oxygen8/control/pot4", "i", kpt4
kccC	OSClisten	giport, "/oxygen8/control/pot5", "i", kpt5
kccD	OSClisten	giport, "/oxygen8/control/pot6", "i", kpt6
kccE	OSClisten	giport, "/oxygen8/control/pot7", "i", kpt7
kccF	OSClisten	giport, "/oxygen8/control/pot8", "i", kpt8

keys	OSClisten	giport, "/oxygen8/keyboard", "ii", knum, kvelo

;  performance code goes here

/*
	printks	"\\nBend: %d, ModWheel: %d, DataSlid: %d\\n\\n\
Pot1: %d, Pot2: %d, Pot3: %d, Pot4: %d\\n Pot5: %d, Pot6: %d, Pot7: %d, 
Pot8: %d\\n\\n\
Key-Num: %d, Veloc: %d\\n", 0.25, kbendr, kmwhl, kdats, kpt1, kpt2, 
kpt3, kpt4,\
kpt5, kpt6, kpt7, kpt8, knum, kvelo
*/

;  global controls
	zkw	kbendr, 1
	zkw	kmwhl, 2
	zkw	kdats, 3

;  knobs
	zkw	kpt1, 4
	zkw	kpt2,	5
	zkw	kpt3, 6
	zkw	kpt4, 7
	zkw	kpt5, 8
	zkw	kpt6, 9
	zkw	kpt7, 10
	zkw	kpt8,	11

;  midi note num and velocity
	zkw	knum,	12
	zkw	kvelo, 13

		endin

/*--- ---*/

		instr	2

gifn1	ftgen	1,0,16384,7,1,16384,-1

;	init

kamp	zkr	13
kamp	=	(kamp / 127) * 8192

kpin	zkr	12
kcps	cpsmid	kpin

kmod	zkr	2
kmod	=	((kmod / 127) * 10000) + 420

;	synth

ab	foscil	kamp, kcps, 2.2449, 1, 0.2, 1
ac	foscil	kamp, kcps, 1.7818, 1, 0.2, 1
ad	foscil	kamp, kcps, 1.4983, 1, 0.2, 1
ae	foscil	kamp, kcps, 1.1892, 1, 0.2, 1
af	foscil	kamp, kcps, 1.0000, 1, 0.2, 1

amix	=	(ab * 0.8) + (ac * 0.8) + (ad * 0.8) + (ae * 0.8) + (af * 0.8)

alpf	rezzy	amix, kmod, 0.77
amix	=	alpf

al1	=	(amix)
awL, awR	reverbsc	al1, al1, 0.89, 18532

amix	=	(amix * 0.8)

aoutL	=	(amix * 0.5) + awL
aoutR	=	(amix * 0.5) + awR

	outs	aoutL, aoutR

	zkcl	1, 16

		endin

/*--- ---*/

Also it is worth noting for this I used a Pure Data patch to convert 
the Oxygen8 keyboard MIDI data to OSC and although it's not Csound, it 
may be a useful reference to users interested in this example and is as 
follows:

#N canvas 273 174 758 442 10;
#X obj 232 212 sendOSC;
#X obj 232 236 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 0
1;
#X floatatom 277 238 5 0 0 0 - - -;
#X msg 50 177 connect localhost \$1;
#X msg 50 196 disconnect;
#X obj 50 160 nbx 5 14 -1e+37 1e+37 0 0 empty empty empty 0 -6 0 10
-262144 -1 -1 57120 256;
#X text 49 143 listener port;
#X obj 16 12 loadbang;
#X obj 16 33 s lb;
#X msg 108 158 4200;
#X obj 145 158 r lb;
#X obj 232 178 prepend send;
#X text 312 292 /oxygen8/control - global indicator;
#X text 405 308 ../mwheel - mod wheel;
#X text 403 325 ../dataslid - data entry slider;
#X text 402 357 ../potX - where X = 1-8 \, the data entry pots;
#X text 355 271 :: OpenSoundControl ADDRESSES ::;
#N canvas 0 22 996 317 OXYGEN 0;
#X obj 556 63 ctlin 1 1;
#X obj 555 101 ctlin 7 1;
#X obj 37 33 ctlin 8 1;
#X obj 106 33 ctlin 9 1;
#X obj 175 33 ctlin 10 1;
#X obj 250 33 ctlin 11 1;
#X obj 477 33 ctlin 14 1;
#X obj 402 33 ctlin 13 1;
#X obj 326 33 ctlin 12 1;
#X obj 555 34 ctlin 15 1;
#X msg 556 82 /oxygen8/control/mwheel \$1;
#X msg 554 120 /oxygen8/control/dataslid \$1;
#X msg 38 60 /oxygen8/control/pot1 \$1;
#X msg 38 79 /oxygen8/control/pot2 \$1;
#X msg 38 99 /oxygen8/control/pot3 \$1;
#X msg 38 118 /oxygen8/control/pot4 \$1;
#X msg 222 60 /oxygen8/control/pot5 \$1;
#X msg 222 79 /oxygen8/control/pot6 \$1;
#X msg 222 99 /oxygen8/control/pot7 \$1;
#X msg 222 118 /oxygen8/control/pot8 \$1;
#X obj 313 240 outlet;
#X obj 555 141 bendin 1;
#X msg 556 161 /oxygen8/control/bender \$1;
#X obj 556 182 notein 1;
#X msg 555 223 /oxygen8/keyboard \$1 \$2;
#X obj 556 203 pack 0 0;
#X connect 0 0 10 0;
#X connect 1 0 11 0;
#X connect 2 0 12 0;
#X connect 3 0 13 0;
#X connect 4 0 14 0;
#X connect 5 0 15 0;
#X connect 6 0 18 0;
#X connect 7 0 17 0;
#X connect 8 0 16 0;
#X connect 9 0 19 0;
#X connect 10 0 20 0;
#X connect 11 0 20 0;
#X connect 12 0 20 0;
#X connect 13 0 20 0;
#X connect 14 0 20 0;
#X connect 15 0 20 0;
#X connect 16 0 20 0;
#X connect 17 0 20 0;
#X connect 18 0 20 0;
#X connect 19 0 20 0;
#X connect 21 0 22 0;
#X connect 22 0 20 0;
#X connect 23 0 25 0;
#X connect 23 1 25 1;
#X connect 24 0 20 0;
#X connect 25 0 24 0;
#X restore 233 155 pd OXYGEN;
#X text 403 341 ../bender - pitch bend wheel;
#X text 308 374 /oxygen8/keyboard - first column is MIDI Note #;
#X text 448 389 second column is Velocity;
#X text 119 50 --% Mapping an Oxygen8 Keyboard to OpenSoundControl
%--;
#X text 202 67 * for use in networked synthesis applications *;
#X text 9 409 David Akbari \, 2005;
#X connect 0 0 1 0;
#X connect 0 1 2 0;
#X connect 3 0 0 0;
#X connect 4 0 0 0;
#X connect 5 0 3 0;
#X connect 7 0 8 0;
#X connect 9 0 5 0;
#X connect 10 0 9 0;
#X connect 11 0 0 0;
#X connect 17 0 11 0;


-David

The documentation in the manual corresponds to the opcode I
wrote. Multiple listeners were allowed but to one queue.  If the code
has been changed then that is nothing to do with me and I expect the
changes to be reflected in the manual, and also explained in this
mailing list.
==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:

> The documentation in the manual corresponds to the opcode I
> wrote. Multiple listeners were allowed but to one queue.  If the code
> has been changed then that is nothing to do with me and I expect the
> changes to be reflected in the manual, and also explained in this
> mailing list.

Yes, I made changes to allow multiple listeners and multiple queues,
as well as string data, and the use of FIFO buffers to avoid dropping
messages if more than one is received in the same control period.
I updated the manual accordingly (also fixed a few minor errors that
previously existed), and added a new example file 'examples/osclisten.csd'
to CVS sources that demonstrates the use of multiple ports.


-------------------------------------------------------
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:

> Also on the topic of this thread, what are some ways that OSCrecv 
> differs from the OSClisten opcode ?

It receives score events as opposed to generic messages. You can
only run one instance of OSCrecv in an orchestra, and it is normally
called from the orchestra header and will then run in the background.
The opcode was not documented yet because I am not sure if it needs
changes, and it may even be removed as I think it may be dangerous
to allow anyone to create arbitrary real time score events (including
bogus ones that may have disastrous results) from a remote machine.

> OSCrecv (null) iSo

The syntax is

     OSCrecv iport, Spath[, iabsp2]

iport and Spath should be obvious. iabsp2 is a boolean flag that
determines how the p2 argument of received events is interpreted:
0 (the default) means that p2 is relative to the current time, while
1 means that p2 is absolute (initially measured from the beginning
of performance, but the time reference can be reset by sending a "T"
event with no arguments).
The first argument of the OSC message is the score opcode (i, f, etc.)
of type "i" (ASCII code), "f" (ASCII code), or "s" (the actual opcode
as a string, for example "i" for note events), and the rest is used
as p-fields which may be of type "i" or "f", and at most one p-field
may be "s".


-------------------------------------------------------
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

You did that after I had changed the code to listen to multiple ports,
and was about too fix the possible race condition.  Unfortunately you
changed it to be incompatible with previous version; I did not.
==John ffitch


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

jpff@codemist.co.uk wrote:

> You did that after I had changed the code to listen to multiple ports,
> and was about too fix the possible race condition.  Unfortunately you
> changed it to be incompatible with previous version; I did not.

Well, I think I should revert to your version if I made changes
that conflict with your work. I am fine with either option as I do
not really need the multiple port/multiple queue functionality.


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I have now reverted my changes to OSCinit, OSClisten, the example
CSD file, and manual entries. For those who have orchestra code that
depends on my (now removed) changes: note that the opcodes no longer
have the "handle" argument, and it is also no longer possible to
receive string values, nor is it safe to receive more than one message
in a single control period.

Istvan Varga wrote:

> jpff@codemist.co.uk wrote:
> 
>> You did that after I had changed the code to listen to multiple ports,
>> and was about too fix the possible race condition.  Unfortunately you
>> changed it to be incompatible with previous version; I did not.
> 
> Well, I think I should revert to your version if I made changes
> that conflict with your work. I am fine with either option as I do
> not really need the multiple port/multiple queue functionality.


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Oct 23, 2005, at 6:00 AM, Istvan Varga wrote:

> note that the opcodes no longer
> have the "handle" argument, and it is also no longer possible to
> receive string values, nor is it safe to receive more than one message
> in a single control period.

:(    x    10000



-David



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

It would be useful to receive strings; I did not like the requirement
for specifying the port on each read.  One the other hand i would
appreciate hearing what the (potential) users want.

To clarify; the options are

1: Multiple listeners, but all messages placed in a single queue, and
not distinguishable by input port, only by OSC address.

2: Multiple listeners, with messages distinguished both by port and
address, and so the opcode needs to quote the port always.

Anyone have any opinions?


==John ffitch


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

jpff@codemist.co.uk wrote:

> It would be useful to receive strings; I did not like the requirement
> for specifying the port on each read.  One the other hand i would
> appreciate hearing what the (potential) users want.
> 
> To clarify; the options are
> 
> 1: Multiple listeners, but all messages placed in a single queue, and
> not distinguishable by input port, only by OSC address.
> 
> 2: Multiple listeners, with messages distinguished both by port and
> address, and so the opcode needs to quote the port always.
> 
> Anyone have any opinions?

If adding a new opcode argument (option 2) is not a problem, then
the OSC opcodes with my modifications could be suitable.


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Oct 23, 2005, at 8:00 AM, jpff@codemist.co.uk wrote:

> 2: Multiple listeners, with messages distinguished both by port and
> address, and so the opcode needs to quote the port always.

> Anyone have any opinions?

Even though it's an extra step, I feel that it's a definite improvement 
to have to specify explicit port index in order to have multiple 
queues. I don't see how you can have listeners on multiple ports 
without it? What of using more than one controller simultaneously?


-David



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

David Akbari wrote:

> Even though it's an extra step, I feel that it's a definite improvement 
> to have to specify explicit port index in order to have multiple queues. 
> I don't see how you can have listeners on multiple ports without it? 
> What of using more than one controller simultaneously?

Any other opinions ? If the addition of the new argument to OSCinit
and OSClisten is accepted, can those versions be used ?


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Oct 24, 2005, at 5:23 AM, Istvan Varga wrote:

> If the addition of the new argument to OSCinit
> and OSClisten is accepted, can those versions be used ?

I sure hope so!

I'd hate to have to keep replacing Opcodes/OSC.c manually after 
updating from CVS just to get this work done!


-David



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Looks like I am out-voted.  I prefer a single queue and allow the OSC
addressing scheme to select between messages, but the balance is
against me.

I just think having to carry an additional parameter which for most
uses will be a constant is overkill. 

==John ffitch


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Oct 24, 2005, at 8:26 AM, jpff@cs.bath.ac.uk wrote:

> I just think having to carry an additional parameter which for most
> uses will be a constant is overkill.

It would seem that there is an increasing trend of using OSC embedded 
in musical devices as a cheap, flexible alternative to MIDI. Thus the 
more devices you have, the more open ports you require (to use Csound 
to listen for). I find typically I am using 3-4 explicit ports for just 
receiving OSC data.

In this way you can easily integrate Csound, Pure Data, SuperCollider, 
and other commercial applications (Reaktor, others), but in order for 
Csound to integrate with the others well, it needs to be able to see 
the incoming data; that's really what it's all about IMO. Those other 
programs sound terrible and you have no control of the parameters. It 
would be nice to have the synthesizers controlling Csound instead of 
those other apps. Also though, that's not to marginalize the importance 
of the other applications in providing Csound with otherwise impossible 
techniques in control data manipulation. It's an added bonus to be able 
to do exactly that over a network.

In other words for most uses, I would argue that there is the need of 
multiple listen cues, especially when using complex networks of 
inter-application communication on the same (or different) machines. As 
soon as you introduce another machine into the system it would seem 
like you're always saying "I wish I had more ports". I find it also 
incredibly important to be able to use OSC as a device for sending MIDI 
over a network, to either our previously mentioned 2nd computer or the 
loopback interface. It's a simple and effective way to add a whole new 
dimension to synthesizer data transmission. We couple this with the 
ability to have multiple instances of Csound with multiple queues (not 
multiple instances of Csound with each a single cue, that gets messy 
quickly) and we can have several Csound synthesizers (computers) 
sitting in a space (acoustic room) and controlling each one separately 
from a single remote host machine. These types of techniques would go 
well with the new Ambisonics opcodes, for example, but also a 
realization of a classic technique from Music history which is that of 
antiphony or hocketing.


-David



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Well, I have now restored the version of the OSC opcodes with the
additional handle argument, as well as the associated example CSD
file and manual entries.

David Akbari wrote:

> On Oct 24, 2005, at 8:26 AM, jpff@cs.bath.ac.uk wrote:
> 
>> I just think having to carry an additional parameter which for most
>> uses will be a constant is overkill.
> 
> 
> It would seem that there is an increasing trend of using OSC embedded in 
> musical devices as a cheap, flexible alternative to MIDI. Thus the more 
> devices you have, the more open ports you require (to use Csound to 
> listen for). I find typically I am using 3-4 explicit ports for just 
> receiving OSC data.
> 
> In this way you can easily integrate Csound, Pure Data, SuperCollider, 
> and other commercial applications (Reaktor, others), but in order for 
> Csound to integrate with the others well, it needs to be able to see the 
> incoming data; that's really what it's all about IMO. Those other 
> programs sound terrible and you have no control of the parameters. It 
> would be nice to have the synthesizers controlling Csound instead of 
> those other apps. Also though, that's not to marginalize the importance 
> of the other applications in providing Csound with otherwise impossible 
> techniques in control data manipulation. It's an added bonus to be able 
> to do exactly that over a network.
> 
> In other words for most uses, I would argue that there is the need of 
> multiple listen cues, especially when using complex networks of 
> inter-application communication on the same (or different) machines. As 
> soon as you introduce another machine into the system it would seem like 
> you're always saying "I wish I had more ports". I find it also 
> incredibly important to be able to use OSC as a device for sending MIDI 
> over a network, to either our previously mentioned 2nd computer or the 
> loopback interface. It's a simple and effective way to add a whole new 
> dimension to synthesizer data transmission. We couple this with the 
> ability to have multiple instances of Csound with multiple queues (not 
> multiple instances of Csound with each a single cue, that gets messy 
> quickly) and we can have several Csound synthesizers (computers) sitting 
> in a space (acoustic room) and controlling each one separately from a 
> single remote host machine. These types of techniques would go well with 
> the new Ambisonics opcodes, for example, but also a realization of a 
> classic technique from Music history which is that of antiphony or 
> hocketing.


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Yes, but that has nothing to do with the point I was making!
Anyway, I give up.

==John ffitch


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Oct 24, 2005, at 4:11 PM, jpff@codemist.co.uk wrote:

> Yes, but that has nothing to do with the point I was making!

Well, could it be possible to keep the same struct and everything but 
change the syntax so that there is no output variable, and that there 
is an additional i-argument to OSCinit where the syntax could be

     OSCinit  iport, [ilistendx]

so that the ilistendx is the listener index similar to zak but with the 
inputs reversed and the ilistendx would be an "o" instead of "i" in the 
OENTRY. (Of course OSClisten would also have to be changed)

It was not a problem before, but with the reverted changes although 
easier to configure, it lacked the flexibility that OSC can really 
provide by not allowing multiple queues... Once you get the system 
working, you have to be able to use it to it's full potential! Of 
course the listener assignment could be re-thought but I think Istvan's 
solution is an efficient and consistent one even though I had to go 
back and fix a few orchestras that were using the older style OSCinit.



-David



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net