hello list,
I am having a problem with the reference file for counter object (GEM). If I open the original file, and click at the bang on right, several times, I never get the message done1. But, in the counter_modified, I get.
Is the original file wrong? Or it was done for another version of GEM?
I had a problem with the value for direction, too. To make the counter go up and down, I had to use 2, and not 3.
What I am trying to do: a counter wherer the max number be randomic. So, I need to know when the counter cycle is finished, to generate another number again. To make this work, I need to know what outlet generates a bang when a cycle is completed, to send the bang to random object.
bye, andrei
Hallo, andreithomaz hat gesagt: // andreithomaz wrote:
I am having a problem with the reference file for counter object (GEM).
You should take care when relying on the counter from Gem. There are several other counter objects and IMHO the one from Cyclone, which is compatible to the Max-counter, is the one to use as [counter]. Generally I don't use [counter] objects at all until this is fixed and we have only one [counter] - at best as an internal in Pd, because otherwise this name clash won't be solved, I fear.
In the meantime I would recommend to build counters with other objects.
Ciao
Frank Barknecht _ ______footils.org__
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
In the meantime I would recommend to build counters with other objects.
like the attached one. It only counts upwards, the downwardscounting is left as an exercise for the reader.
Ciao
Frank Barknecht _ ______footils.org__
I've built a few devices that accept MIDI as a control signal and they don't work with the latest version of PD. I'm not sure but it looks to me like where a ctlout object used to send Channel , Controller Number , and Control Value it is only sending channel information if there is a channel change. This makes a lot of sense I guess to save bandwidth. First of all could someone confirm that this is what is happening . It would be a hassle for me now to rewrite all the firmware in these devices. They are all waiting for channel data each transmission. I'm not sure when this change in PD happened or whether it is something else that is going on. Everything seems to work for me under PD 0.34.4 in Windows but 0.37 under Linux is where I'm having problems. If indeed Channel Number is only transmitted when it changes is there an easy way to send it with every transmission till I get a chance to reprogram all my devices. Thanks! Jim
Hallo, jim ruxton hat gesagt: // jim ruxton wrote:
I've built a few devices that accept MIDI as a control signal and they don't work with the latest version of PD. I'm not sure but it looks to me like where a ctlout object used to send Channel , Controller Number and Control Value it is only sending channel information if there is a channel change.
Not here: ctlin is sending out all three numbers at every change of a controller value. Maybe there is something wrong with your patch, like hot and cold inlets messed up?
Could you create a test patch that shows the behaviour you get?
Ciao
Frank Barknecht _ ______footils.org__
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
jim ruxton hat gesagt: // jim ruxton wrote:
I've built a few devices that accept MIDI as a control signal and they don't work with the latest version of PD. I'm not sure but it looks to me like where a ctlout object used to send Channel , Controller Number and Control Value it is only sending channel information if there is a channel change.
Not here: ctlin is sending out all three numbers at every change of a controller value. Maybe there is something wrong with your patch, like hot and cold inlets messed up?
Argh, sorry, forget what I wrote: you were referring to ctlOUT.
Ciao
Frank Barknecht _ ______footils.org__
Here's a conjecture... maybe the MIDI driver (or the OS) has suddenly decided to start filtering the extra bytes out. That would be bad, but not the first bad thing I've seen a MSW driver and/or OS do...
Miller
On Mon, Jun 21, 2004 at 10:40:57AM +0200, Frank Barknecht wrote:
Hallo, jim ruxton hat gesagt: // jim ruxton wrote:
I've built a few devices that accept MIDI as a control signal and they don't work with the latest version of PD. I'm not sure but it looks to me like where a ctlout object used to send Channel , Controller Number and Control Value it is only sending channel information if there is a channel change.
Not here: ctlin is sending out all three numbers at every change of a controller value. Maybe there is something wrong with your patch, like hot and cold inlets messed up?
Could you create a test patch that shows the behaviour you get?
Ciao
Frank Barknecht _ ______footils.org__
PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://iem.at/cgi-bin/mailman/listinfo/pd-list
Thanks Miller,
I'd love to blame this on MSW but it works on version 0.34 in Windows but not 0.37 in Linux. I guess I should try 0.37 in Windows to see if the code has changed there as well. jim ----- Original Message ----- From: "Miller Puckette" mpuckett@man104-1.ucsd.edu To: pd-list@iem.at Sent: Monday, June 21, 2004 10:21 PM Subject: Re: [PD] Was there a change in how MIDI is transmitted ????
Here's a conjecture... maybe the MIDI driver (or the OS) has suddenly decided to start filtering the extra bytes out. That would be bad, but not the first bad thing I've seen a MSW driver and/or OS do...
Miller
On Mon, Jun 21, 2004 at 10:40:57AM +0200, Frank Barknecht wrote:
Hallo, jim ruxton hat gesagt: // jim ruxton wrote:
I've built a few devices that accept MIDI as a control signal and they don't work with the latest version of PD. I'm not sure but it looks to me like where a ctlout object used to send Channel , Controller Number and Control Value it is only sending channel information if there is a channel change.
Not here: ctlin is sending out all three numbers at every change of a controller value. Maybe there is something wrong with your patch, like hot and cold inlets messed up?
Could you create a test patch that shows the behaviour you get?
Ciao
Frank Barknecht _ ______footils.org__
PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://iem.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://iem.at/cgi-bin/mailman/listinfo/pd-list
But Jim, can't you change your receiver to handle running status? It''s part of the MIDI spec after all... You just need a variable to hold the last status byte received. When you get a data byte with no preceding status byte, use the running status. Martin
----- Original Message ----- From: "Jim Ruxton" cinetron@passport.ca To: msp@ucsd.edu; pd-list@iem.at Sent: Tuesday, June 22, 2004 1:54 AM Subject: Re: [PD] Was there a change in how MIDI is transmitted ????
Thanks Miller,
I'd love to blame this on MSW but it works on version 0.34 in Windows but not 0.37 in Linux. I guess I should try 0.37 in Windows to see if the code has changed there as well. jim ----- Original Message ----- From: "Miller Puckette" mpuckett@man104-1.ucsd.edu To: pd-list@iem.at Sent: Monday, June 21, 2004 10:21 PM Subject: Re: [PD] Was there a change in how MIDI is transmitted ????
Here's a conjecture... maybe the MIDI driver (or the OS) has suddenly decided to start filtering the extra bytes out. That would be bad, but not the first bad thing I've seen a MSW driver and/or OS do...
Miller
On Mon, Jun 21, 2004 at 10:40:57AM +0200, Frank Barknecht wrote:
Hallo, jim ruxton hat gesagt: // jim ruxton wrote:
I've built a few devices that accept MIDI as a control signal and they don't work with the latest version of PD. I'm not sure but it looks to me like where a ctlout object used to send Channel , Controller Number and Control Value it is only sending channel information if there is a channel change.
Not here: ctlin is sending out all three numbers at every change of a controller value. Maybe there is something wrong with your patch, like hot and cold inlets messed up?
Could you create a test patch that shows the behaviour you get?
Ciao
Frank Barknecht _ ______footils.org__
PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://iem.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://iem.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://iem.at/cgi-bin/mailman/listinfo/pd-list
HI Martin, haven't talked to you for a while .. Yes I will eventually do this. Just that I have a number of different devices with different code ie. midi to pwm, midi to stepper, emg to midi , accelerometer to midi etc. etc. . Eventually I'll crack open all the boxes and reprogram the chips. I guess I didn't pay close enough attention to the midi spec :-( I was just surprised when they stopped working. For now I'll just send a note-on between transmissions as suggested by Cyrille. Bandwidth isn't a big issue on my next project. Jim
But Jim, can't you change your receiver to handle running status? It''s part of the MIDI spec after all... You just need a variable to hold the last status byte received. When you get a data byte with no preceding status byte, use the running status. Martin
----- Original Message ----- From: "Jim Ruxton" cinetron@passport.ca To: msp@ucsd.edu; pd-list@iem.at Sent: Tuesday, June 22, 2004 1:54 AM Subject: Re: [PD] Was there a change in how MIDI is transmitted ????
Thanks Miller,
I'd love to blame this on MSW but it works on version 0.34 in Windows but not 0.37 in Linux. I guess I should try 0.37 in Windows to see if the code has changed there as well. jim ----- Original Message ----- From: "Miller Puckette" mpuckett@man104-1.ucsd.edu To: pd-list@iem.at Sent: Monday, June 21, 2004 10:21 PM Subject: Re: [PD] Was there a change in how MIDI is transmitted ????
Here's a conjecture... maybe the MIDI driver (or the OS) has suddenly decided to start filtering the extra bytes out. That would be bad, but not the first bad thing I've seen a MSW driver and/or OS do...
Miller
On Mon, Jun 21, 2004 at 10:40:57AM +0200, Frank Barknecht wrote:
Hallo, jim ruxton hat gesagt: // jim ruxton wrote:
I've built a few devices that accept MIDI as a control signal and they don't work with the latest version of PD. I'm not sure but it looks to me like where a ctlout object used to send Channel , Controller Number and Control Value it is only sending channel information if there is a channel change.
Not here: ctlin is sending out all three numbers at every change of a controller value. Maybe there is something wrong with your patch, like hot and cold inlets messed up?
Could you create a test patch that shows the behaviour you get?
Ciao
Frank Barknecht _ ______footils.org__
PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://iem.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://iem.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://iem.at/cgi-bin/mailman/listinfo/pd-list
I know, I keep forgetting about it. If it had been called 'current status', then it would make more sense...This link has a good algorithm for running status: http://www.borg.com/~jglatt/tech/midispec/run.htm Martin
----- Original Message ----- From: "jim ruxton" cinetron@passport.ca To: "Martin Peach" martinrp@vax2.concordia.ca; pd-list@iem.at Sent: Tuesday, June 22, 2004 1:00 PM Subject: Re: [PD] Was there a change in how MIDI is transmitted ????
HI Martin, haven't talked to you for a while .. Yes I will eventually do this. Just that I have a number of different devices with different code ie. midi to pwm, midi to stepper, emg to midi , accelerometer to midi etc. etc. . Eventually I'll crack open all the boxes and reprogram the chips. I guess I didn't pay close enough attention to the midi spec :-( I was just surprised when they stopped working. For now I'll just send a note-on between transmissions as suggested by Cyrille. Bandwidth isn't a big issue on my next project. Jim
But Jim, can't you change your receiver to handle running status? It''s
part
of the MIDI spec after all... You just need a variable to hold the last status byte received. When you
get
a data byte with no preceding status byte, use the running status. Martin
----- Original Message ----- From: "Jim Ruxton" cinetron@passport.ca To: msp@ucsd.edu; pd-list@iem.at Sent: Tuesday, June 22, 2004 1:54 AM Subject: Re: [PD] Was there a change in how MIDI is transmitted ????
Thanks Miller,
I'd love to blame this on MSW but it works on version 0.34 in Windows
but
not 0.37 in Linux. I guess I should try 0.37 in Windows to see if the
code
has changed there as well. jim ----- Original Message ----- From: "Miller Puckette" mpuckett@man104-1.ucsd.edu To: pd-list@iem.at Sent: Monday, June 21, 2004 10:21 PM Subject: Re: [PD] Was there a change in how MIDI is transmitted ????
Here's a conjecture... maybe the MIDI driver (or the OS) has suddenly decided to start filtering the extra bytes out. That would be bad, but not the first bad thing I've seen a MSW driver and/or OS do...
Miller
On Mon, Jun 21, 2004 at 10:40:57AM +0200, Frank Barknecht wrote:
Hallo, jim ruxton hat gesagt: // jim ruxton wrote:
I've built a few devices that accept MIDI as a control signal and they don't work with the latest version of PD. I'm not sure but it looks to me like where a ctlout object used to send Channel , Controller Number and Control Value it is only sending channel information if there is a channel change.
Not here: ctlin is sending out all three numbers at every change of a controller value. Maybe there is something wrong with your patch, like hot and cold inlets messed up?
Could you create a test patch that shows the behaviour you get?
Ciao
Frank Barknecht _ ______footils.org__
PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://iem.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://iem.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://iem.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://iem.at/cgi-bin/mailman/listinfo/pd-list
Hi, Thanks a lot Martin. I'll stick this algorithm in my boxes when I get a chance. I've been thinking of going the route of OSC as I think you guys have. That will be a bigger rewrite/ hardware change though. Jim
I know, I keep forgetting about it. If it had been called 'current status', then it would make more sense...This link has a good algorithm for running status: http://www.borg.com/~jglatt/tech/midispec/run.htm Martin
----- Original Message ----- From: "jim ruxton" cinetron@passport.ca To: "Martin Peach" martinrp@vax2.concordia.ca; pd-list@iem.at Sent: Tuesday, June 22, 2004 1:00 PM Subject: Re: [PD] Was there a change in how MIDI is transmitted ????
HI Martin, haven't talked to you for a while .. Yes I will eventually do this. Just that I have a number of different devices with different code ie. midi to pwm, midi to stepper, emg to midi , accelerometer to midi etc. etc. . Eventually I'll crack open all the boxes and reprogram the chips. I guess I didn't pay close enough attention to the midi spec :-( I was just surprised when they stopped working. For now I'll just send a note-on between transmissions as suggested by Cyrille. Bandwidth isn't a big issue on my next project. Jim
But Jim, can't you change your receiver to handle running status? It''s
part
of the MIDI spec after all... You just need a variable to hold the last status byte received. When you
get
a data byte with no preceding status byte, use the running status. Martin
----- Original Message ----- From: "Jim Ruxton" cinetron@passport.ca To: msp@ucsd.edu; pd-list@iem.at Sent: Tuesday, June 22, 2004 1:54 AM Subject: Re: [PD] Was there a change in how MIDI is transmitted ????
Thanks Miller,
I'd love to blame this on MSW but it works on version 0.34 in Windows
but
not 0.37 in Linux. I guess I should try 0.37 in Windows to see if the
code
has changed there as well. jim ----- Original Message ----- From: "Miller Puckette" mpuckett@man104-1.ucsd.edu To: pd-list@iem.at Sent: Monday, June 21, 2004 10:21 PM Subject: Re: [PD] Was there a change in how MIDI is transmitted ????
Here's a conjecture... maybe the MIDI driver (or the OS) has suddenly decided to start filtering the extra bytes out. That would be bad, but not the first bad thing I've seen a MSW driver and/or OS do...
Miller
On Mon, Jun 21, 2004 at 10:40:57AM +0200, Frank Barknecht wrote:
Hallo, jim ruxton hat gesagt: // jim ruxton wrote:
>I've built a few devices that accept MIDI as a control signal and >they don't work with the latest version of PD. I'm not sure but it >looks to me like where a ctlout object used to send Channel , >Controller Number and Control Value it is only sending channel >information if there is a channel change. > > >
> Not here: ctlin is sending out all three numbers at every change of a controller value. Maybe there is something wrong with your patch, like hot and cold inlets messed up?Could you create a test patch that shows the behaviour you get?
Ciao
Frank Barknecht _ ______footils.org__
PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://iem.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://iem.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://iem.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://iem.at/cgi-bin/mailman/listinfo/pd-list
I can find nothing in the source code for pd that deals with running status, so I think it's happening at the level of the system MIDI driver. All note-on messages are sent as three bytes to the system MIDI driver on every platform.
Martin
"Jim Ruxton" cinetron@passport.ca To: msp@ucsd.edu; pd-list@iem.at Sent: Tuesday, June 22, 2004 1:54 AM Subject: Re: [PD] Was there a change in how MIDI is transmitted ????
Thanks Miller,
I'd love to blame this on MSW but it works on version 0.34 in Windows but not 0.37 in Linux. I guess I should try 0.37 in Windows to see if the code has changed there as well. jim
HI Martin,
Thanks for looking into this. I recently upgraded to Fedora . Maybe that is when it happened. Perhaps I loaded a new MIDI system driver at that point. Hmm guess there isn't much I can do about it but change my firmware. Thanks again. Jim
I can find nothing in the source code for pd that deals with running status, so I think it's happening at the level of the system MIDI driver. All note-on messages are sent as three bytes to the system MIDI driver on every platform.
Martin
"Jim Ruxton" cinetron@passport.ca To: msp@ucsd.edu; pd-list@iem.at Sent: Tuesday, June 22, 2004 1:54 AM Subject: Re: [PD] Was there a change in how MIDI is transmitted ????
Thanks Miller,
I'd love to blame this on MSW but it works on version 0.34 in Windows but not 0.37 in Linux. I guess I should try 0.37 in Windows to see if the code has changed there as well. jim
PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://iem.at/cgi-bin/mailman/listinfo/pd-list
jim ruxton wrote:
I've built a few devices that accept MIDI as a control signal and they don't work with the latest version of PD. I'm not sure but it looks to me like where a ctlout object used to send Channel , Controller Number , and Control Value it is only sending channel information if there is a channel change. This makes a lot of sense I guess to save bandwidth. First of all could someone confirm that this is what is happening .
yes, pd, like most recent midi software does not send the 1st (status) bit if it's the same than the one one the previus message. it's conform to midi specification. (look at "running status" on google.)
It would be a hassle for me now to rewrite all the firmware in these devices. They are all waiting for channel data each transmission. I'm not sure when this change in PD happened or whether it is something else that is going on. Everything seems to work for me under PD 0.34.4 in Windows but 0.37 under Linux is where I'm having problems. If indeed Channel Number is only transmitted when it changes is there an easy way to send it with every transmission till I get a chance to reprogram all my devices. Thanks!
if bandwidth is not a problem, you can send a note on befor each ctlout message. This will force pd to send the 1st bit everytime.
hope that help
cyrille
Jim
PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://iem.at/cgi-bin/mailman/listinfo/pd-list
Thanks Cyrille and Frank, This must have changed in a fairly recent version of PD or maybe I've been using an older version than I thought :-(
if bandwidth is not a problem, you can send a note on befor each ctlout message. This will force pd to send the 1st bit everytime.
I'll take a look at this. Do you mean a " noteout "? Is there a way that I can see the actual midi data going out so I can see what I'm sending? I'm using Linux. Thanks Jim
hope that help
cyrille
Jim
PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://iem.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://iem.at/cgi-bin/mailman/listinfo/pd-list
Hallo, jim ruxton hat gesagt: // jim ruxton wrote:
I'll take a look at this. Do you mean a " noteout "? Is there a way that I can see the actual midi data going out so I can see what I'm sending? I'm using Linux.
You could use a virtual midi connection using the snd-virmidi virtual card, which works even with only Pd as clients. Example:
$ su -c modprobe snd-virmidi
$ aconnect -lio
client 0: 'System' [type=kernel]
0 'Timer '
1 'Announce '
client 64: 'Rawmidi 0 - M Audio Audiophile 24/96 MPU-401' [type=kernel]
0 'M Audio Audiophile 24/96 MPU-401'
client 72: 'Virtual Raw MIDI 1-0' [type=kernel]
0 'VirMIDI 1-0 '
client 73: 'Virtual Raw MIDI 1-1' [type=kernel]
0 'VirMIDI 1-1 '
client 74: 'Virtual Raw MIDI 1-2' [type=kernel]
0 'VirMIDI 1-2 '
client 75: 'Virtual Raw MIDI 1-3' [type=kernel]
0 'VirMIDI 1-3
$ aconnect 72:0 74:0
$ aconnect -lio client 0: 'System' [type=kernel] 0 'Timer ' 1 'Announce ' client 64: 'Rawmidi 0 - M Audio Audiophile 24/96 MPU-401' [type=kernel] 0 'M Audio Audiophile 24/96 MPU-401' client 72: 'Virtual Raw MIDI 1-0' [type=kernel] 0 'VirMIDI 1-0 ' Connecting To: 74:0 client 73: 'Virtual Raw MIDI 1-1' [type=kernel] 0 'VirMIDI 1-1 ' client 74: 'Virtual Raw MIDI 1-2' [type=kernel] 0 'VirMIDI 1-2 ' Connected From: 72:0 client 75: 'Virtual Raw MIDI 1-3' [type=kernel] 0 'VirMIDI 1-3
$ pd -midioutdev 11 -midiindev 13 (using 11 = 'Virtual Raw MIDI 1-0' + 1 and 13 = 'Virtual Raw MIDI 1-2' + 1)
Now open "Test Audio and MIDI" and if you enable "MIDI OUT" you should see the notes coming in at "MIDI IN".
Ciao
Frank Barknecht _ ______footils.org__
hello,
Frank Barknecht wrote:
Hallo, jim ruxton hat gesagt: // jim ruxton wrote:
I'll take a look at this. Do you mean a " noteout "? Is there a way that I can see the actual midi data going out so I can see what I'm sending? I'm using Linux.
You could use a virtual midi connection using the snd-virmidi virtual card, which works even with only Pd as clients. Example:
using a software to see the data you send will not help for the running status problem. if you ask pd to send a control out 2, channel 0, value = 63, and then a control out 3, chanel 0, value = 31 you'll get 5 bytes on your midi line :
b'10110000' Control change channel 0 status b'00000001' control number (2 - 1) b'01000000' =63d nothing here because it will not send the same status 2 times. b'00000010' control number (3 - 1) b'00100000' =31d
most software (including pd) will told you that midi information was :
ControlChange 2, channel 0, value = 63 and ControlChange 3, channel 0, value = 31
because midi specification allows it. but you will not receive the 6 bytes your expecting. only 5.
to check this on the midi transmition line, I use an oscilloscope.
but if you replace all your ctlout object with :
| [t f b] | | | [1< | | | [noteout] | [ctlout]
(this is because note-on status is not the same than control change status)
everything should then work as espected. it's something I use a lot...
it's not a problem if you don't nead lot's of bandwidth. otherwise, you'll have to make your device compatible to running status...
cyrille
$ su -c modprobe snd-virmidi
$ aconnect -lio client 0: 'System' [type=kernel] 0 'Timer ' 1 'Announce ' client 64: 'Rawmidi 0 - M Audio Audiophile 24/96 MPU-401' [type=kernel] 0 'M Audio Audiophile 24/96 MPU-401' client 72: 'Virtual Raw MIDI 1-0' [type=kernel] 0 'VirMIDI 1-0 ' client 73: 'Virtual Raw MIDI 1-1' [type=kernel] 0 'VirMIDI 1-1 ' client 74: 'Virtual Raw MIDI 1-2' [type=kernel] 0 'VirMIDI 1-2 ' client 75: 'Virtual Raw MIDI 1-3' [type=kernel] 0 'VirMIDI 1-3
$ aconnect 72:0 74:0
$ aconnect -lio client 0: 'System' [type=kernel] 0 'Timer ' 1 'Announce ' client 64: 'Rawmidi 0 - M Audio Audiophile 24/96 MPU-401' [type=kernel] 0 'M Audio Audiophile 24/96 MPU-401' client 72: 'Virtual Raw MIDI 1-0' [type=kernel] 0 'VirMIDI 1-0 ' Connecting To: 74:0 client 73: 'Virtual Raw MIDI 1-1' [type=kernel] 0 'VirMIDI 1-1 ' client 74: 'Virtual Raw MIDI 1-2' [type=kernel] 0 'VirMIDI 1-2 ' Connected From: 72:0 client 75: 'Virtual Raw MIDI 1-3' [type=kernel] 0 'VirMIDI 1-3
$ pd -midioutdev 11 -midiindev 13 (using 11 = 'Virtual Raw MIDI 1-0' + 1 and 13 = 'Virtual Raw MIDI 1-2' + 1)
Now open "Test Audio and MIDI" and if you enable "MIDI OUT" you should see the notes coming in at "MIDI IN".
Ciao
Thanks for the suggestion Frank. I'm using snd-virmidi to get the second port on my Midisport 2x2 but never thought of using it to see the midi stream. I'll give it a try. I was thinking more along the lines of " cat /dev/midi or something like that. Jim
Hallo, jim ruxton hat gesagt: // jim ruxton wrote:
I'll take a look at this. Do you mean a " noteout "? Is there a way that I can see the actual midi data going out so I can see what I'm sending? I'm using Linux.
You could use a virtual midi connection using the snd-virmidi virtual card, which works even with only Pd as clients. Example:
$ su -c modprobe snd-virmidi
$ aconnect -lio client 0: 'System' [type=kernel] 0 'Timer ' 1 'Announce ' client 64: 'Rawmidi 0 - M Audio Audiophile 24/96 MPU-401' [type=kernel] 0 'M Audio Audiophile 24/96 MPU-401' client 72: 'Virtual Raw MIDI 1-0' [type=kernel] 0 'VirMIDI 1-0 ' client 73: 'Virtual Raw MIDI 1-1' [type=kernel] 0 'VirMIDI 1-1 ' client 74: 'Virtual Raw MIDI 1-2' [type=kernel] 0 'VirMIDI 1-2 ' client 75: 'Virtual Raw MIDI 1-3' [type=kernel] 0 'VirMIDI 1-3
$ aconnect 72:0 74:0
$ aconnect -lio client 0: 'System' [type=kernel] 0 'Timer ' 1 'Announce ' client 64: 'Rawmidi 0 - M Audio Audiophile 24/96 MPU-401' [type=kernel] 0 'M Audio Audiophile 24/96 MPU-401' client 72: 'Virtual Raw MIDI 1-0' [type=kernel] 0 'VirMIDI 1-0 ' Connecting To: 74:0 client 73: 'Virtual Raw MIDI 1-1' [type=kernel] 0 'VirMIDI 1-1 ' client 74: 'Virtual Raw MIDI 1-2' [type=kernel] 0 'VirMIDI 1-2 ' Connected From: 72:0 client 75: 'Virtual Raw MIDI 1-3' [type=kernel] 0 'VirMIDI 1-3
$ pd -midioutdev 11 -midiindev 13 (using 11 = 'Virtual Raw MIDI 1-0' + 1 and 13 = 'Virtual Raw MIDI 1-2' + 1)
Now open "Test Audio and MIDI" and if you enable "MIDI OUT" you should see the notes coming in at "MIDI IN".
Ciao
I'm having trouble with PD recognizing the virtual ports. I've loaded snd-virmidi and when I do:
$ aconnect -lio client 0: 'System' [type=kernel] 0 'Timer ' 1 'Announce ' Connecting To: 128:0 client 80: 'Virtual Raw MIDI 2-0' [type=kernel] 0 'VirMIDI 2-0 ' client 81: 'Virtual Raw MIDI 2-1' [type=kernel] 0 'VirMIDI 2-1 ' client 82: 'Virtual Raw MIDI 2-2' [type=kernel] 0 'VirMIDI 2-2 ' client 83: 'Virtual Raw MIDI 2-3' [type=kernel] 0 'VirMIDI 2-3 '
Then :
$ aconnect 80:0 82:0
client 0: 'System' [type=kernel] 0 'Timer ' 1 'Announce ' Connecting To: 128:0 client 80: 'Virtual Raw MIDI 2-0' [type=kernel] 0 'VirMIDI 2-0 ' Connecting To: 82:0 client 81: 'Virtual Raw MIDI 2-1' [type=kernel] 0 'VirMIDI 2-1 ' client 82: 'Virtual Raw MIDI 2-2' [type=kernel] 0 'VirMIDI 2-2 ' Connected From: 80:0 client 83: 'Virtual Raw MIDI 2-3' [type=kernel] 0 'VirMIDI 2-3 '
Then:
$ pd -midiindev 23 -midioutdev 21
I get :
couldn't open MIDI input device 22 couldn't open MIDI output device 20 opened 0 MIDI input device(s) and 0 MIDI output device(s). Sample width set to 2 bytes
The only device I can use is mididev 3 ie.
$ pd -mididev 3 doesn't generate "couldn't open ......."
?? ( I don't have a real device attached at this point) . Output of :
$ pd -listdev
oops: ALSA cards not reported in order? input devices:
- Intel 82801CA-ICH3 (hardware)
- Intel 82801CA-ICH3 (plug-in)
- VirMIDI (hardware)
- VirMIDI (plug-in)
output devices:
- Intel 82801CA-ICH3 (hardware)
- Intel 82801CA-ICH3 (plug-in)
- VirMIDI (hardware)
- VirMIDI (plug-in)
API number 1
no midi input devices found no midi output devices found couldn't open MIDI input device 0 couldn't open MIDI output device 0 opened 0 MIDI input device(s) and 0 MIDI output device(s).
Any thoughts on what I'm doing wrong? Jim
Hallo, jim ruxton hat gesagt: // jim ruxton wrote:
I'll take a look at this. Do you mean a " noteout "? Is there a way that I can see the actual midi data going out so I can see what I'm sending? I'm using Linux.
You could use a virtual midi connection using the snd-virmidi virtual card, which works even with only Pd as clients. Example:
$ su -c modprobe snd-virmidi
$ aconnect -lio client 0: 'System' [type=kernel] 0 'Timer ' 1 'Announce ' client 64: 'Rawmidi 0 - M Audio Audiophile 24/96 MPU-401' [type=kernel] 0 'M Audio Audiophile 24/96 MPU-401' client 72: 'Virtual Raw MIDI 1-0' [type=kernel] 0 'VirMIDI 1-0 ' client 73: 'Virtual Raw MIDI 1-1' [type=kernel] 0 'VirMIDI 1-1 ' client 74: 'Virtual Raw MIDI 1-2' [type=kernel] 0 'VirMIDI 1-2 ' client 75: 'Virtual Raw MIDI 1-3' [type=kernel] 0 'VirMIDI 1-3
$ aconnect 72:0 74:0
$ aconnect -lio client 0: 'System' [type=kernel] 0 'Timer ' 1 'Announce ' client 64: 'Rawmidi 0 - M Audio Audiophile 24/96 MPU-401' [type=kernel] 0 'M Audio Audiophile 24/96 MPU-401' client 72: 'Virtual Raw MIDI 1-0' [type=kernel] 0 'VirMIDI 1-0 ' Connecting To: 74:0 client 73: 'Virtual Raw MIDI 1-1' [type=kernel] 0 'VirMIDI 1-1 ' client 74: 'Virtual Raw MIDI 1-2' [type=kernel] 0 'VirMIDI 1-2 ' Connected From: 72:0 client 75: 'Virtual Raw MIDI 1-3' [type=kernel] 0 'VirMIDI 1-3
$ pd -midioutdev 11 -midiindev 13 (using 11 = 'Virtual Raw MIDI 1-0' + 1 and 13 = 'Virtual Raw MIDI 1-2' + 1)
Now open "Test Audio and MIDI" and if you enable "MIDI OUT" you should see the notes coming in at "MIDI IN".
Ciao
It's ok got it to work by creating symlinks between /dev/snd/C2/Dx and /dev/midi2x . Thanks again Frank. Jim
I'm having trouble with PD recognizing the virtual ports. I've loaded snd-virmidi and when I do:
$ aconnect -lio client 0: 'System' [type=kernel] 0 'Timer ' 1 'Announce ' Connecting To: 128:0 client 80: 'Virtual Raw MIDI 2-0' [type=kernel] 0 'VirMIDI 2-0 ' client 81: 'Virtual Raw MIDI 2-1' [type=kernel] 0 'VirMIDI 2-1 ' client 82: 'Virtual Raw MIDI 2-2' [type=kernel] 0 'VirMIDI 2-2 ' client 83: 'Virtual Raw MIDI 2-3' [type=kernel] 0 'VirMIDI 2-3 '
Then :
$ aconnect 80:0 82:0
client 0: 'System' [type=kernel] 0 'Timer ' 1 'Announce ' Connecting To: 128:0 client 80: 'Virtual Raw MIDI 2-0' [type=kernel] 0 'VirMIDI 2-0 ' Connecting To: 82:0 client 81: 'Virtual Raw MIDI 2-1' [type=kernel] 0 'VirMIDI 2-1 ' client 82: 'Virtual Raw MIDI 2-2' [type=kernel] 0 'VirMIDI 2-2 ' Connected From: 80:0 client 83: 'Virtual Raw MIDI 2-3' [type=kernel] 0 'VirMIDI 2-3 '
Then:
$ pd -midiindev 23 -midioutdev 21
I get :
couldn't open MIDI input device 22 couldn't open MIDI output device 20 opened 0 MIDI input device(s) and 0 MIDI output device(s). Sample width set to 2 bytes
The only device I can use is mididev 3 ie.
$ pd -mididev 3 doesn't generate "couldn't open ......."
?? ( I don't have a real device attached at this point) . Output of :
$ pd -listdev
oops: ALSA cards not reported in order? input devices:
- Intel 82801CA-ICH3 (hardware)
- Intel 82801CA-ICH3 (plug-in)
- VirMIDI (hardware)
- VirMIDI (plug-in)
output devices:
- Intel 82801CA-ICH3 (hardware)
- Intel 82801CA-ICH3 (plug-in)
- VirMIDI (hardware)
- VirMIDI (plug-in)
API number 1
no midi input devices found no midi output devices found couldn't open MIDI input device 0 couldn't open MIDI output device 0 opened 0 MIDI input device(s) and 0 MIDI output device(s).
Any thoughts on what I'm doing wrong? Jim
Hallo, jim ruxton hat gesagt: // jim ruxton wrote:
I'll take a look at this. Do you mean a " noteout "? Is there a way that I can see the actual midi data going out so I can see what I'm sending? I'm using Linux.
You could use a virtual midi connection using the snd-virmidi virtual card, which works even with only Pd as clients. Example:
$ su -c modprobe snd-virmidi
$ aconnect -lio client 0: 'System' [type=kernel] 0 'Timer ' 1 'Announce ' client 64: 'Rawmidi 0 - M Audio Audiophile 24/96 MPU-401' [type=kernel] 0 'M Audio Audiophile 24/96 MPU-401' client 72: 'Virtual Raw MIDI 1-0' [type=kernel] 0 'VirMIDI 1-0 ' client 73: 'Virtual Raw MIDI 1-1' [type=kernel] 0 'VirMIDI 1-1 ' client 74: 'Virtual Raw MIDI 1-2' [type=kernel] 0 'VirMIDI 1-2 ' client 75: 'Virtual Raw MIDI 1-3' [type=kernel] 0 'VirMIDI 1-3
$ aconnect 72:0 74:0
$ aconnect -lio client 0: 'System' [type=kernel] 0 'Timer ' 1 'Announce ' client 64: 'Rawmidi 0 - M Audio Audiophile 24/96 MPU-401' [type=kernel] 0 'M Audio Audiophile 24/96 MPU-401' client 72: 'Virtual Raw MIDI 1-0' [type=kernel] 0 'VirMIDI 1-0 ' Connecting To: 74:0 client 73: 'Virtual Raw MIDI 1-1' [type=kernel] 0 'VirMIDI 1-1 ' client 74: 'Virtual Raw MIDI 1-2' [type=kernel] 0 'VirMIDI 1-2 ' Connected From: 72:0 client 75: 'Virtual Raw MIDI 1-3' [type=kernel] 0 'VirMIDI 1-3
$ pd -midioutdev 11 -midiindev 13 (using 11 = 'Virtual Raw MIDI 1-0'
- 1 and 13 = 'Virtual Raw MIDI 1-2' + 1)
Now open "Test Audio and MIDI" and if you enable "MIDI OUT" you should see the notes coming in at "MIDI IN". Ciao
PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://iem.at/cgi-bin/mailman/listinfo/pd-list
-
andreithomaz -
cyrille henry -
Frank Barknecht -
Jim Ruxton -
jim ruxton
-
Martin Peach -
Miller Puckette