On Fri, April 18, 2008 00:27, Fons Adriaensen wrote:
> On Thu, Apr 17, 2008 at 11:59:50PM +0100, Rui Nuno Capela wrote:
>
>
>> problem 1 is an old one and is due on lack of a better mapping
>> algorithm between actual jack graph and qjackctl patchbay models:
>>
>> - jack graph is represented by connecting nodes which are the actual
>> individual ports;
>>
>> - qjackctl patchbay is represented by nodes (sockets), which aggregates
>> an ordered set of ports (plugs), intentionally connectible in turn, when
>> actively available.
>
> The 'ordered set' seems to follow different rules than the
> ordering of ports in the main display. A similar thing happens if you
> select two apps expecting that connections will be made in the order they
> are displayed - usually it's different.
>
> Whatever the model, I assume it can represent an arbitrary set of
> connections. If not it's a wrong model. If it can, why doesn't that happen
> when you make a snapshot ? What is the purpose of making *other*
> connections ?
>
i'm sure the biggest problem here is the braindead snapshot feature which
doesn't do what you really want ootb. and the keyword here is the ootb;)
suppose you have this connection scenario:
client_a:out_1 -> client_b:in_3
client_a:out_2 -> client_b:in_4
client_a:out_3 -> client_b:in_2
client_a:out_4 -> client_b:in_1
then the snapshot will make it like:
socket_a -> socket_b
client_a client_b
out_1 in_1
out_2 in_2
out_3 in_3
out_4 in_4
if you activate this it won't do what you want, sure. that's why you'll
have to tweak the patchbay layout a little. read on
the correct patchbay would be exactly this one:
socket_a1 -> socket_b2
client_a client_b
out_1 in_3
out_2 in_4
socket_a2 -> socket_b2
client_a client_b
out_3 in_2
out_4 in_1
you see? at least you should have to copy either said sockets, remove half
of the ports(plugs) on each one and reorder the plugs in one other case.
imho, the big question is not whether the patchbay model doesn't fit to
all purposes, but whether the current super-naive snapshot mapping is any
better than not having one :)
>> the other two problems (2+3) are somewhat moot imho. yes, you'll always
>> have to save the patchbay profile, so what?
>
> A collection of useless files that have to be deleted.
> I like to keep my home dir clean (the junk yards are at
> deeper levels). If you could at least save to an existing file the pile
> wouldn't grow so fast. Imagine that emacs wouldn't allow you overwrite a
> file...
>
aha. so you can't save to an existing file? now that's a bug that i wasn't
aware of. afaict that doesn't happen here, as it always asks whether you
want to replace the old file or not.
i guess a split into the old-school "Save" and "Save As..." options is in
order?
> As far as I can see there is no technical reason why a
> patchbay should saved before it can be active. Nor is there any good
> reason to impose this rule.
>
yes, you're right, there is no reason at all but an old implementation
one. a very old in fact (4 years?:)
>> all suggestions are welcome,
>
> I have three:
>
>
> 1. Snapshot = exact copy of existing connections.
yeah right :o)
> 2. 'Current' patchbay exists without being saved.
to be 'Active' a patchbay must be materialized in a file first. i still
believe this is a minor hindrance but i get the point.
> 3. Allow overwriting files.
are you sure that's not possible already?
>
>
> I imagine that 2+3 would actually simplify the code.
>
eheh, i'm always found to quote this "don't fix what isn't broken" :))
snapshots aside, maybe the biggest miss on this current patchbay
implementation is that it hasn't support for jack-midi, yet ;)
thanks for the heads-up suggestions, nevertheless
cyaa
--
rncbc aka Rui Nuno Capela
rncbc@xxxxxxxxx
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
