Drawbacks of the second "One port per each staff" option
Actually we don't have any limitations from the OS for the number of ports
per application. (I asked in #jack)
Correction:
There is a possible maximum number of ports in the system (in all
applications in total), which can be defined when starting jackd.
Also, jackd2 can have a limit chosen at compile time (not sure).
Anyway, now I see the main problem:
Imagine that we have a score with 10 instruments. It looks and plays well.
1. You have 10 imaginary scores with 10 instruments in each score. If there
is some conflicts, ports will be renamed. Also, I can not guarantee that
application with 100 ports would work stable (can arise system lacks).
2. We can't save connections. Suppose we have two scores: one uses acoustic
guitar sound, and one uses distorted guitar sound. This staves have the
same name "Guitar". Also suppose we have 2 external synthesizers for
acoustic and distorted sound. We'll open only one score in one moment.
Opening score one:
/******************
*Out ports: Guitar
*
*Syn1: Acoustic
*Syn2: Distorted
*******************/
Close it. Open the second. We'll get:
/******************
*Out ports: Guitar
*
*Syn1: Acoustic
*Syn2: Distorted
*******************/
No difference? Yes. We don't have any information how to connect them. Even
if staves have different names we don't know how to connect them. (Actually
we can, but you need to keep the same name of staves in all your scores. As
an ID. But it is a workaround, staff name is not for that.)
So, in each case we have a *connection problem*. But...stop. A connection
problem was described in my first mail. And this "One port per each staff"
approach was described as one of the possible solutions. We got the same
problem.
Strike out it.
*Offtop*
It was an explanation for those who might be interested in this idea.
*/Offtop*
Now let's talk about assigning channels to staves:
1. It's commonly used in other notation or sound editing software. No need
to learn something new.
2. We save an ability to connect ports automatically after opening score.
3. Different scores could use different names for parts (as should be).
4. It makes people hap..Well, that's enough.
Using mixer wasn't the best idea. Now we have to add 2 spinboxes: to change
port and channel. Two new elements could be too much for this tiny window.
Using an instrument window is much better, I think. Also, this controls can
be displayed only if "Use JACK MIDI" checkbox is checked.
Now interface could look like this:[0]
What do you think about it? Should I change something? Developers, I think
I need your approval.
p.s.
Feel free to write about features related to JACK that you want to be
implemented in MuseScore.
You can find me in #musescore as igevorse.
p.p.s
Sorry for the long letter :).
[0]: https://lut.im/se396lam/fEK9513X
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer
