18 Apr
2008
18 Apr
'08
6:51 a.m.
On Fri, April 18, 2008 00:27, Fons Adriaensen wrote:
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?
yeah right :o)
On Thu, Apr 17, 2008 at 11:59:50PM +0100, Rui Nuno
Capela wrote:
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 :)
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 ?
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...
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. 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(a)rncbc.org