It's a good idea.  We have to see how the midi IO modules
(ie. portmidi) can cope with this.

Victor
>
> I asked about this a while back but got no response, does
> that mean no  one is working on multi port midi for
> csound5?
>
> I consider this to be one of csounds main weaknesses for
> real time work.  I realize it is also a problem because
> any solution introduces backwards  compatibility
> nightmares. If nothing else is being done, I propose the
> following solution, which I think would be a good addition
> nontheless.
>
> We add an opcode, midiinrouter or somesuch. It acts like
> midi in with  two differences, obviously multi ports, but
> also have it possible for it  to empty the entire midiin
> queue and dispatch all events, *within one  kpass*. This
> is the one horrible thing about midiin for realtime work
> with low kcycles. I'm envisioning being able to have a
> midi router  instrument that simply empties the whole
> queue and then makes event  calls to send the data to
> other instruments, thus having any midi events  currently
> in the queue in one kpass all synced up. This would
> actually  *improve* midi event synchronization at the
> expense of max one kpass  latency instead of the opposite.
> Other instruments have only to act as  if an event call of
> the right amp is a midi off or act like a turn off  call
> is a note off.
>
> Thoughts? If no one else is interested I will try looking
> into the  opcode myself, though it may take me a while as
> I am quite busy with  some other ( bread and butter )
> coding right now. And I would like input  by better
> csounders to do it right.
>
> Thanks
> Iain
>
>
>
> -------------------------------------------------------
> 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. For more info visit:
> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


-------------------------------------------------------
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. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Iain,

By multiple ports do you mean using multiple MIDI I/O devices ?

If that's the case I had a problem with that too with multiple in 
devices, as the -M flag only supports one inport per instance of 
Csound. I've found an elegant solution can be to multiplex your MIDI 
data from multiple ports in a software bus (I use MidiPipe for OSX 
freeware http://www.versiontracker.com/dyn/moreinfo/mac/16154) and then 
send all data to a single output. This is also possible using Pure Data 
as a router. You then specify -M to point to the output of your 
software multiplexing solution. This is only for multiple in devices 
per single instance of Csound.

This does not address the problem of MIDI output on several ports from 
within an instance of Csound. I can see where your ideas are getting at 
and I certainly welcome this and any other initiative to try and 
improve Csound's realtime performance functionality! (it would be nice 
to send MIDI data to several synths and use Csound just as "meta 
control" - with Csound's extensive library of statistical and 
mathematical subroutines to implement interesting control data for 
several external synthesizers!!)


-David

On Nov 18, 2005, at 2:45 PM, Victor Lazzarini wrote:

> It's a good idea.  We have to see how the midi IO modules
> (ie. portmidi) can cope with this.
>
> Victor
>>
>> I asked about this a while back but got no response, does
>> that mean no  one is working on multi port midi for
>> csound5?
>>
>> I consider this to be one of csounds main weaknesses for
>> real time work.  I realize it is also a problem because
>> any solution introduces backwards  compatibility
>> nightmares. If nothing else is being done, I propose the
>> following solution, which I think would be a good addition
>> nontheless.
>>
>> We add an opcode, midiinrouter or somesuch. It acts like
>> midi in with  two differences, obviously multi ports, but
>> also have it possible for it  to empty the entire midiin
>> queue and dispatch all events, *within one  kpass*. This
>> is the one horrible thing about midiin for realtime work
>> with low kcycles. I'm envisioning being able to have a
>> midi router  instrument that simply empties the whole
>> queue and then makes event  calls to send the data to
>> other instruments, thus having any midi events  currently
>> in the queue in one kpass all synced up. This would
>> actually  *improve* midi event synchronization at the
>> expense of max one kpass  latency instead of the opposite.
>> Other instruments have only to act as  if an event call of
>> the right amp is a midi off or act like a turn off  call
>> is a note off.
>>
>> Thoughts? If no one else is interested I will try looking
>> into the  opcode myself, though it may take me a while as
>> I am quite busy with  some other ( bread and butter )
>> coding right now. And I would like input  by better
>> csounders to do it right.
>>
>> Thanks
>> Iain



-------------------------------------------------------
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. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

> It's a good idea.  We have to see how the midi IO modules
> (ie. portmidi) can cope with this.

Ok, now that I know there is interest, I will think about some issues 
and pull open midiin, event, and turnoff to see how they work. The main 
stumbler I can see off the top of my head is that event currently gives 
us no way to identify each instance created. It may be that a version of 
event that imbeds some kind of identifier with the note instance would 
solve a lot of problems combined with a turnoff version that is directed 
at the specific instance. Perhaps a memory address of the spawned 
instance could be kept? I am just brainstorming here, I could be waaay 
off base. But it would be darn useful ... ; )

Istvan, do you have any thoughts on this? I know you have looked at 
event thoroughly and made the incredibly useful turnoff opcode. Any 
ideas on how we could pinpoint who gets turned off?

Iain


-------------------------------------------------------
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. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Victor Lazzarini wrote:

> It's a good idea.  We have to see how the midi IO modules
> (ie. portmidi) can cope with this.

The MIDI module interface should not be a problem (as long as
the plugin does not make the assumption that a single CSOUND*
instance will never open more than one input and output device,
but that is easy to avoid, and the existing drivers may very
well be OK). However, changes would need to be made to the way
MIDI is handled internally by the engine, and the existing
opcodes would need to be updated to support multiple devices.


-------------------------------------------------------
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. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

>> It's a good idea.  We have to see how the midi IO modules
>> (ie. portmidi) can cope with this.
> 
> 
> The MIDI module interface should not be a problem (as long as
> the plugin does not make the assumption that a single CSOUND*
> instance will never open more than one input and output device,
> but that is easy to avoid, and the existing drivers may very
> well be OK). However, changes would need to be made to the way
> MIDI is handled internally by the engine, and the existing
> opcodes would need to be updated to support multiple devices.

The point of my proposal is that we could add multi port support as an 
interm solution without changin opcodes by *only* adding a multiport 
souped up midiin opcode.

Iain


-------------------------------------------------------
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. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net