Back again with all that stuff using lights, video and music
So, several questions :
1. Real-Time Preemption
Probably the most important: I wondered whether qlc will work
"normally" on a system based on a real-time preempted kernel, with
rtprio on audio apps only?
I mean, for audio, we have to get this real-time preemption, or we will
have some latency(ies) when playing, which is not suitable. If we want
to synch lights with music using MIDI, we have to use that kind of
preemption too (especially using Led PARs, and so on, which don't have
any latency of lighting, or a very small one).
Actually, I observed that when using a midi sequencer directly speaking
with qlc, qlc seemed to have some trouble lighting Led PARs quickly. I
find it strange, as it's not the case when I used directly a virtual
keyboard. That's why I'm thinking about this preemption.
2. Way of connecting to alsa / way of savinf alsa connections
So, basically, the problem I talked about the first time is always
there. As far as I know ALSA(_SEQ) API (which is not very much), I don't
really understand why a connection made outside qlc wouldn't work. But,
actually, that's what is happening.
When choosing alsa port in qlc it works perfectly, whereas when
connecting from qjackctl or aconnect, MIDI informations do not reach
It's a pity, as there might be a lot of configurations in which it is
preferable to get qlc wired from outside:
- using qjackctl patchbay
- using scripts when having a very big setup to launch
- using lashd (I think qlc is not lashable yet)
It's even more a pity as qlc seems not to remind well what port it was
connected to. I personnaly use it with a midi router called QMIDIROUTE
just before. QMIDIROUTE has as many outputs as you want, let's say 9 in
my case. QLC is supposed to be plugged to the eighths. If I plug it to
the 8th (in qlc), then save my session, than reboot, than reopen qlc it
won't connect to the 8th. Actually, it almost always connect to the 9th
(but I'm not sure it's really reproductible).
I think this might be linked to a lack of robustess towards launching
order of midi programs: if port numbers are used in the saved file, then
it cannot work as port numbers may change from one time to another.
Though, there are ways to get program name, and so on with alsa, wichi
is a bit more robust.
Though, it is not the majestic way neither, as you may have several
instances of the same soft running.
So the best way would probably be, imho, to work a bit like Ardour does:
1. ask the user whether it has or has not to autoconnect the session
a. if yes : autoconnect using port names
b. if no : just let connect via outside ways (aconnect, aconnectgui,
Another way I've seen, but not experimented much, is the way of qtractor
which directly makes qjackctl appear in the GUI. I don't know how it's
done, but it could be a decent manner, as it keeps quite simple to use
for non-used-to-jack-and-midi users, although it will keep the option to
get plugged from outside.
Anyway, I think the autoconnection should be optionnal (at least through
a command line).
I don't have much time by now, but, if I can get a bit more, I will
check if I can work on it with my very limited developpment skills).
On Wed, Jul 15, 2009 at 07:23:40PM +0200, tyranorl@... wrote :
> I don't know if we can call it a bug, but here is what happens:
> When using a complete MIDI solution, including midi controller, jack,
> qmidiroute, and so on, QLC will get MIDI messages only if the connection is made
> in QLC, and not if we do it from qjackctl or with aconnect. Even if we use the
> very same port. I find it a bit sad, as it may be interested to do it both ways
> (like in Ardour for audio connections).
> See you.
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize
> details at: http://p.sf.net/sfu/Challenge
> qlc-devel mailing list