for example, here is a small script: --- test.ck --- Std.atoi(me.arg(0)) => int port; MidiIn min; MidiMsg msg; <<< port >>>; min.open(port); while (true) { min => now; while (!min.recv(msg)) { <<< msg.data1, msg.data2, msg.data3 >>>; } } --- end test.ck --- if I run %> chuck-jack test.ck:0 a midi in port appears in qjackctl. if I run %> chuck-jack test.ck:0 test.ck:0 I still have only one midi in port in qjackctl Am I doing it wrong ? tom On Fri, Oct 29, 2010 at 09:13:45PM +0200, Kassen wrote:

On 29 October 2010 21:04, Thomas Girod wrote:

hi there.

Is there a way to open multiple midi ports with chuck ? (on linux)

This should simply work as advertised. Defining several ports, then opening those should do the trick. Could you describe what you did and where and how it fails?

Yours, Kas.

hi

That one will open port 0 twice. This should mean that ChucK will open it once, then have two internal shreds that both listen to the same port. I think this should help;

%> chuck-jack test.ck:0 test.ck:1

That should make ChucK open two ports, one for each shred. The first shred gets port 0, then second gets port 1 That is, of course, assuming nothing is horribly wrong in ChucK or in Linux.

How far does that get you? Kas.

That's what I thought too, as it seemed logical. but it doesn't work. Let's say I don't have any alsa-midi apps running. in qjackctl, I only have "Midi Through" (in and out) % chuck-jack test.ck:0 this will create a new MidiIn and connect it to "Midi Through (out)". % chuck-jack test.ck:1 this won't work, with this message :

[chuck]: MidiIn: couldn't open MIDI port 1...

my conclusion: the port parameter to the MidiIn.open() function is not the number of the port you open, but the port number of the source or the target to which it is supposed to be connected. ... which isn't that useful, in my opinion. tom

Correction to pervious post: when I talk about audio, I mean MIDI. On Sun, Oct 31, 2010 at 1:54 AM, Stefan Blixt wrote:

I have been able to connect to the same device in the past, and send messages from two ChucK shreds to one MIDI thing. Have you tried if it works even if it just shows up as one device in Jack?

What you call "port" I usually call "device". A device is either Jack, or an audio interface or some other sound thing. You see these listed when you run chuck --probe, along with their respective device number, which is what you give to min.open(<number>).

You probably know this, but don't confuse these with MIDI channels, which are 16 to a device (or port) and are specified inside each MIDI message that you send.

/Stefan

On Sat, Oct 30, 2010 at 9:43 PM, Thomas Girod wrote:

...

hi

...

That one will open port 0 twice. This should mean that ChucK will open it once, then have two internal shreds that both listen to the same port. I think this should help;

%> chuck-jack test.ck:0 test.ck:1

That should make ChucK open two ports, one for each shred. The first shred gets port 0, then second gets port 1 That is, of course, assuming nothing is horribly wrong in ChucK or in Linux.

How far does that get you? Kas.

That's what I thought too, as it seemed logical. but it doesn't work. Let's say I don't have any alsa-midi apps running. in qjackctl, I only have "Midi Through" (in and out)

% chuck-jack test.ck:0

this will create a new MidiIn and connect it to "Midi Through (out)".

% chuck-jack test.ck:1

this won't work, with this message :

...

[chuck]: MidiIn: couldn't open MIDI port 1...

my conclusion: the port parameter to the MidiIn.open() function is not the number of the port you open, but the port number of the source or the target to which it is supposed to be connected.

... which isn't that useful, in my opinion.

tom _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- Release me, insect, or I will destroy the Cosmos!

-- Release me, insect, or I will destroy the Cosmos!

@kassen & stefan thank you guys for your advices, especially for the "chuck --probe" thing - I finally managed to get where I wanted. by the way, anyone with a launchpad can test the result: http://github.com/jiyunatori/chuck/blob/master/fourth.ck example: chuck fourth.ck:1:3:2:4 1 = launchpad midi port 3 = synth midi port 2 = starting octave 4 = interval between notes a scale is built for each row of the controller by using the given interval. the next row is the same scale shifted by one semitone. have fun On Sun, Oct 31, 2010 at 03:54:17AM +0100, Kassen wrote:

Hey Tom!

That's what I thought too, as it seemed logical. but it doesn't work.

Ok. Well, that should work so we'll have to trace where it fails then....  

Let's say I don't have any alsa-midi apps running. in qjackctl, I only have "Midi Through" (in and out)

And no hardware MIDI ports either, right?  

% chuck-jack test.ck:0

this will create a new MidiIn and connect it to "Midi Through (out)".

Yes. good.  

% chuck-jack test.ck:1

this won't work, with this message :

> [chuck]: MidiIn: couldn't open MIDI port 1...

my conclusion: the port parameter to the MidiIn.open() function is not the number of the port you open, but the port number of the source or the target to which it is supposed to be connected.

... which isn't that useful, in my opinion.

I think I understand the issue. Inside of ChucK and in your code there are objects of type MidiIn. The objects are abstractions for hardware ports and/or virtual ports that might exist on your system. We link the objects to the ports using .open( int device ) These objects have names in our code, like "min" in your case; I tend to name mine after the controller or synth used which I find helps keep things clear. The objects in our code don't have numbers, typically.

The numbers you saw correspond to the number of the device. If you run this;

chuck --probe

(might be "chuck-jack --probe" in your case) At your terminal you will see a list of available soundcards and MIDI devices with their ID number. The MIDI stuff will be at the bottom of the output of that command. The numbers of those correspond to the numbers for devices to open using the .open() function. I suspect that you would only see a single input device there, with number "0". If so then that would explain the failure at opening the second devices (numbered at "1").

If that's right that would mean you only have a single virtual port on your system and no hardware attached (at least no working hardware). That would mean that -for once  ;¬) -  ChucK would be working fine and the question becomes what you were trying to do and how you could accomplish that.

Could you confirm this is all more or less right? If something is still unclear we can take another step back.

Yours, Kas.