[PD-dev] pd041-test6 auto(connect) feedbacks MIDI.

IOhannes m zmoelnig zmoelnig at iem.at
Tue Sep 18 15:12:08 CEST 2007


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 at 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 at iem.at
>>> http://lists.puredata.info/listinfo/pd-dev
>> _______________________________________________
>> PD-dev mailing list
>> PD-dev at iem.at
>> http://lists.puredata.info/listinfo/pd-dev
> 





More information about the Pd-dev mailing list