Hello !
Since pure data just connects alle MIDI-ins and MIDI-outs to his instance under alsamidi also the MIDI-Through is connected which in fact is a feedback a therefore dangerous and bad.
If this behaviour is changes all old patches using MIDI (I used aconnect to connect) doesnt work anymore.
Is there a reason for this behaviour ?
I think on alsa midi the philosophy is that connection should be done by alsa tools. There are templates and so on so that automatically the right devices are connected, no need for pd to do this (as for other programms which doesnt respect this).
mfg winfried ritsch
I think alsa-MIDI is only included since very recently (I got it from soneone else, I forget who) so it shouldn't be a problem to change the behavior.
Do you think the correct thing would be just to open one MIDI input and output device?
Anyway, OSS MIDI is much better API than ALSA, I don't know why anyone uses the latter :)
M On Thu, Sep 06, 2007 at 04:44:03PM +0200, Winfried Ritsch wrote:
Hello !
Since pure data just connects alle MIDI-ins and MIDI-outs to his instance under alsamidi also the MIDI-Through is connected which in fact is a feedback a therefore dangerous and bad.
If this behaviour is changes all old patches using MIDI (I used aconnect to connect) doesnt work anymore.
Is there a reason for this behaviour ?
I think on alsa midi the philosophy is that connection should be done by alsa tools. There are templates and so on so that automatically the right devices are connected, no need for pd to do this (as for other programms which doesnt respect this).
mfg winfried ritsch
--
- ao.Univ.Prof. DI Winfried Ritsch
- ritsch@iem.at - http://iem.at/ritsch
- Institut fuer Elektronische Musik und Akustik
- University of Music and Dramatic Art Graz
- Tel. ++43-316-389-3510 (3170) Fax ++43-316-389-3171
- PGP-ID 69617A69 (see keyserver http://wwwkeys.eu.gpg.net/)
--
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Hello,
I think alsa-MIDI is only included since very recently (I got it from soneone else, I forget who) so it shouldn't be a problem to change the behavior.
Do you think the correct thing would be just to open one MIDI input and output device?
Ok I try a draft for a solution:
In ALSA-MIDI can be seen as a patchbay, each program opens as many MIDI-Ports it needs to connect to other MIDI-Ports dedicated to devices on the system. Since modern Computer can ave a lot of virtual MIDI devices (one of them is ALSA MIDIThrough by default nowadays on new ALSA-Driver) or sequencer, synthis and external MIDI-Connection, its not that easy anymore to decide which is the right one to connect to. So in my opinion no connection should be made by default to do not risk feedback loud sound or something else on startup of patch.
OSS-MIDI is easier (especial for PD), but is not properiate for modern system where a lot of integration between apps and environment has to be done, and some devices have no OSS driver at all.
Three solution I see:
a) just open external devices, but maybe there are more than one, which can be run by different PD-Instances, so not optimal.
b) having a commandline (and maybe a GUI) to connect to other devices, like we had to choose one device on OSS-MIDI.
c) let beautiful ;-) ALSA-Tools do the job. Eg.: in qjackcontrol, you can make templates so each puredata Port is connected automatically to defined group of MIDI-Ports.
The fast solution for now is just make a commandline switch which enables the automatic connection like it does now and default is none like in previous PD-versions:
in s_midi_alsa.c set
int autoconnect = 1; -> int autoconnect = 0;
My Proposal is:
lets use correctly the command line switches: . -midiindev ... -- midi in device list; e.g., "1,3" for first and third -midioutdev ... -- midi out device list, same format -mididev ... -- specify -midioutdev and -midiindev together
They should connect to the specific MIDI-Device but they doesnt, instead the number of args means how much ports pd-creates and (funny) if you have more than one port it does no autoconnect to all.
PD needs an extra command line or better use the commandline arg -alsamidi <num> to define the number of ports to create, of course there can be different numbers of inputs and outputs so maybe:
-alsamidi [num[,numinputs]] where num...number of ports numins... if number of inputs if it should be different to number of ouputs if no number is given at least one MIDI-port is opened, this is different to now, where -alsamidi doesnt create an MIDI-Port only -mididev... does.
(comment: I dont know why we need more than one MIDI-Port if there is an alsapatchbay, but who knows...)
The other thing is, I used is the object [aconnect], where you can patch from pd, but aconnect ist not that comfortable, since it operates on numbers not on names, so maybe we should enhance it.
mfg winfried
Anyway, OSS MIDI is much better API than ALSA, I don't know why anyone uses the latter :)
M
On Thu, Sep 06, 2007 at 04:44:03PM +0200, Winfried Ritsch wrote:
Hello !
Since pure data just connects alle MIDI-ins and MIDI-outs to his instance under alsamidi also the MIDI-Through is connected which in fact is a feedback a therefore dangerous and bad.
If this behaviour is changes all old patches using MIDI (I used aconnect to connect) doesnt work anymore.
Is there a reason for this behaviour ?
I think on alsa midi the philosophy is that connection should be done by alsa tools. There are templates and so on so that automatically the right devices are connected, no need for pd to do this (as for other programms which doesnt respect this).
mfg winfried ritsch
--
- ao.Univ.Prof. DI Winfried Ritsch
- ritsch@iem.at - http://iem.at/ritsch
- Institut fuer Elektronische Musik und Akustik
- University of Music and Dramatic Art Graz
- Tel. ++43-316-389-3510 (3170) Fax ++43-316-389-3171
- PGP-ID 69617A69 (see keyserver http://wwwkeys.eu.gpg.net/)
--
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Hello,
I just forgot one Problem which I have with starting more PD-Instances and/or Ports is the naming. Just now its
... sprintf(portname,"Pure Data Midi-In %d",i+1); ... sprintf(portname,"Pure Data Midi-Out %d",i+1); ... snd_seq_client_info_set_name(alsainfo,"Pure Data"); ...
so in the MIDI Patchbay its named like this. It would be good to specifiy another base name like "Pure Data" for the Instance so in a template you can just discriminate between PD instances. (Maybe thats the optional argument for -alsamidi instead of number of ports mentioned in my previous mail).
... char *alsamidiname = "Pure Data" (here option overwrites alsamidiname) ... sprintf(portname,"%s Midi-In %d",alsamidiname,i+1); ... sprintf(portname,"%s Midi-Out %d",alsamidiname,i+1); ... snd_seq_client_info_set_name(alsainfo,alsamidiname); ...
mfg winfried
I think alsa-MIDI is only included since very recently (I got it from soneone else, I forget who) so it shouldn't be a problem to change the behavior.
Do you think the correct thing would be just to open one MIDI input and output device?
Ok I try a draft for a solution:
In ALSA-MIDI can be seen as a patchbay, each program opens as many MIDI-Ports it needs to connect to other MIDI-Ports dedicated to devices on the system. Since modern Computer can ave a lot of virtual MIDI devices (one of them is ALSA MIDIThrough by default nowadays on new ALSA-Driver) or sequencer, synthis and external MIDI-Connection, its not that easy anymore to decide which is the right one to connect to. So in my opinion no connection should be made by default to do not risk feedback loud sound or something else on startup of patch.
OSS-MIDI is easier (especial for PD), but is not properiate for modern system where a lot of integration between apps and environment has to be done, and some devices have no OSS driver at all.
Three solution I see:
a) just open external devices, but maybe there are more than one, which can be run by different PD-Instances, so not optimal.
b) having a commandline (and maybe a GUI) to connect to other devices, like we had to choose one device on OSS-MIDI.
c) let beautiful ;-) ALSA-Tools do the job. Eg.: in qjackcontrol, you can make templates so each puredata Port is connected automatically to defined group of MIDI-Ports.
The fast solution for now is just make a commandline switch which enables the automatic connection like it does now and default is none like in previous PD-versions:
in s_midi_alsa.c set
int autoconnect = 1; -> int autoconnect = 0;My Proposal is:
lets use correctly the command line switches: . -midiindev ... -- midi in device list; e.g., "1,3" for first and third -midioutdev ... -- midi out device list, same format -mididev ... -- specify -midioutdev and -midiindev together
They should connect to the specific MIDI-Device but they doesnt, instead the number of args means how much ports pd-creates and (funny) if you have more than one port it does no autoconnect to all.
PD needs an extra command line or better use the commandline arg -alsamidi <num> to define the number of ports to create, of course there can be different numbers of inputs and outputs so maybe:
-alsamidi [num[,numinputs]] where num...number of ports numins... if number of inputs if it should be different to number of ouputs if no number is given at least one MIDI-port is opened, this is different to now, where -alsamidi doesnt create an MIDI-Port only -mididev... does.
(comment: I dont know why we need more than one MIDI-Port if there is an alsapatchbay, but who knows...)
The other thing is, I used is the object [aconnect], where you can patch from pd, but aconnect ist not that comfortable, since it operates on numbers not on names, so maybe we should enhance it.
mfg winfried
Anyway, OSS MIDI is much better API than ALSA, I don't know why anyone uses the latter :)
M
On Thu, Sep 06, 2007 at 04:44:03PM +0200, Winfried Ritsch wrote:
Hello !
Since pure data just connects alle MIDI-ins and MIDI-outs to his instance under alsamidi also the MIDI-Through is connected which in fact is a feedback a therefore dangerous and bad.
If this behaviour is changes all old patches using MIDI (I used aconnect to connect) doesnt work anymore.
Is there a reason for this behaviour ?
I think on alsa midi the philosophy is that connection should be done by alsa tools. There are templates and so on so that automatically the right devices are connected, no need for pd to do this (as for other programms which doesnt respect this).
mfg winfried ritsch
--
- ao.Univ.Prof. DI Winfried Ritsch
- ritsch@iem.at - http://iem.at/ritsch
- Institut fuer Elektronische Musik und Akustik
- University of Music and Dramatic Art Graz
- Tel. ++43-316-389-3510 (3170) Fax ++43-316-389-3171
- PGP-ID 69617A69 (see keyserver http://wwwkeys.eu.gpg.net/)
--
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Winfried Ritsch wrote:
c) let beautiful ;-) ALSA-Tools do the job. Eg.: in qjackcontrol, you can make templates so each puredata Port is connected automatically to defined group of MIDI-Ports.
i am not sure whether these tools are really so "beautiful". qjackctl templates can be very annoying. having to rely on external programs, makes it _not_ work out of the box, which was the main motivation to write the autoconnecting stuff, after talking to ccrma's fernando at the icmc in barcelona (2005): he assured me (and i haven't tested, since i don't use MIDI so often outside of Pd), that every "modern" application would at least offer the possibility to automatically connect to all physical devices.
however, the bug described by wini is indeed nasty.
the original idea was, to only connect to "real world" devices (which exlcudes a virtual midi-thru); however i haven't found a way to find out how "real" a midi device is; all documentation i have found is non-existant, vague or simply wrong. i come to the conclusion that this is _not_ the way to go.
The fast solution for now is just make a commandline switch which enables the automatic connection like it does now and default is none like in previous PD-versions:
in s_midi_alsa.c set
int autoconnect = 1; -> int autoconnect = 0;
now the good thing about the "autoconnect" parameter is, that it is already dynamic. (read: you can turn it off!) the bad thing is, that it is rather non-intuitive how to do that: Pd only attempts to auto-connect if it has one single alsa port. input and output are dealed with separately. e.g. if you open 1 alsamidi IN port and 2 alsamidi OUT ports, then all available devices should connect TO Pd, but Pd will not get automatically connected to other devices.
this is of course not a very clever decision. however it allows one, to "disable" the autoconnect stuff.
My Proposal is:
lets use correctly the command line switches: . -midiindev ... -- midi in device list; e.g., "1,3" for first and third -midioutdev ... -- midi out device list, same format -mididev ... -- specify -midioutdev and -midiindev together
They should connect to the specific MIDI-Device but they doesnt, instead the number of args means how much ports pd-creates
if i understand this correctly, it is a good idea: "-midiindev 1" would automatically connect Pd's input port with the "1st" available midi device. "-midiindev 1,2" would do the same, but also merge the "2nd" midi device into the stream.
so this would be a way to specify the midi routing in and out Pd.
the problem is, that this doesn't map so good to to the way alsa numbers its devices.
however, this could be managed by using more complicated strings, e.g. "-midiindev 1:3" would connect device#1, port#3 to the input of Pd. omitting the port-specification (e.g "-midiindev 2") could specify that either all ports of the specified device or only the 1st one should be used (whatever makes more sense; people who use midi more than me should have their say on this)
one could also add a special dev-secification "auto" or "all" to automatically connect all (hardware?) devices.
and (funny) if you have more than one port it does no autoconnect to all.
see above for an explanation of this not-so-funny behaviour.
PD needs an extra command line or better use the commandline arg -alsamidi <num> to define the number of ports to create, of course there can be different numbers of inputs and outputs so maybe:
-alsamidi [num[,numinputs]] where num...number of ports numins... if number of inputs if it should be different to number of ouputs if no number is given at least one MIDI-port is opened, this is different to now, where -alsamidi doesnt create an MIDI-Port only -mididev... does.
i don't think it is a good idea to change the behaviour of a commandline flag to incompatibility. currently "pd -alsamidi 4" will start Pd with alsamidi enabled and it will try to open the patch-file "4".
but then, i also think that it is not such a good idea to have the "-alsamidi" flag at all; imo, there should be a flag for specifying the midi (and/or audio) infrastructure to use, like "-midi alsa" could replace the "-alsamidi" flag, and "-midi oss" would enforce the use of OSS midi. the same goes for "-audio"
but of course: what for? (oh, when i have a Pd compiled without jack-support, Pd will fail to start with the "-jack" flag, because it doesn't know it; also, a general flag with special args maps better to the way this information is stored in the .pdsettings)
having said all that, i agree that we need a way to specify the number of input/output ports separately. this however raises the question: how does this relate to the connection information (given with "-mididev")?
a probably better idea would be to make the "-mididev" string even more complicated: "-midiindev 1=3:2,2=1:2" would connect dev#3,port#2 to Pd's port#1 and dev#1,port#2 to Pd's port#2
(comment: I dont know why we need more than one MIDI-Port if there is an alsapatchbay, but who knows...)
because the alsapatchbay _merges_ MIDI data. this might not be what you want. (by using several ports i can distinguish between more than 16 MIDI-keyboards)
The other thing is, I used is the object [aconnect], where you can patch from pd, but aconnect ist not that comfortable, since it operates on numbers not on names, so maybe we should enhance it.
well yes, the problems are: - the symbolic name need not be non-ambiguous (e.g. several instances of Pd use the same name (this we can fix); several instances of the el-cheapo behringer fader-boxes use the same name (this we cannot fix (without hacking the drivers)) - Pd is so bad at generating symbols with spaces (and a lot of symbolic device names have spaces in them...)
mfg winfried
Anyway, OSS MIDI is much better API than ALSA, I don't know why anyone uses the latter :)
M
On Thu, Sep 06, 2007 at 04:44:03PM +0200, Winfried Ritsch wrote:
Hello !
Since pure data just connects alle MIDI-ins and MIDI-outs to his instance under alsamidi also the MIDI-Through is connected which in fact is a feedback a therefore dangerous and bad.
If this behaviour is changes all old patches using MIDI (I used aconnect to connect) doesnt work anymore.
Is there a reason for this behaviour ?
I think on alsa midi the philosophy is that connection should be done by alsa tools. There are templates and so on so that automatically the right devices are connected, no need for pd to do this (as for other programms which doesnt respect this).
mfg winfried ritsch
--
- ao.Univ.Prof. DI Winfried Ritsch
- ritsch@iem.at - http://iem.at/ritsch
- Institut fuer Elektronische Musik und Akustik
- University of Music and Dramatic Art Graz
- Tel. ++43-316-389-3510 (3170) Fax ++43-316-389-3171
- PGP-ID 69617A69 (see keyserver http://wwwkeys.eu.gpg.net/)
--
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Thu, Sep 06, 2007 at 03:48:23PM -0700, Miller Puckette wrote:
I think alsa-MIDI is only included since very recently (I got it from soneone else, I forget who) so it shouldn't be a problem to change the behavior.
Do you think the correct thing would be just to open one MIDI input and output device?
Yes, with Winfried's point about need different names for different Pd instances. It would be so great if one could tell Pd which specific alsa midi devices one wanted it to connect to on the command line instad of having to use aconnect on the command line, or aconnectgui after starting Pd.
Anyway, OSS MIDI is much better API than ALSA, I don't know why anyone uses the latter :)
Because the Alsa system is much much friendlier and more flexible than the OSS system for the user. That sucks that it's more complicated for the programmer.
Best,
Chris.
------------------- http://mccormick.cx
-
Chris McCormick -
IOhannes m zmoelnig -
Miller Puckette -
Winfried Ritsch