On 09. nov. 2017 00:51, Will Godfrey wrote:
On Wed, 8 Nov 2017 20:36:34 +0100
Jesper Lloyd <jpl.lloyd@xxxxxxxxx> wrote:
That's not what I meant, but it sounds like a better idea than what I had
This is one thing we hadn't figured out yet. A radio button seems
tempting, because it's simple to implement, but it also is a bit
mysterious to the user. What is the "Extended format" checkbox in the
save dialog? What does it do? Maybe we can have the checkbox next to the
controllers, "save as part of instrument". Or is that what you meant?
in mind.
controllers for a part synced to e.g. an existing midi input, where bendFor loading, my favoured solution would be to have an "xiy" marked as
such in the bank list, and be able to choose to load the full package
with associated controller settings _or_ only the instrument (using e.g.
Ctrl-click for the latter).
Definitely yes to the former. The latter I have no strong opinion either
way.
For the latter I'm thinking of the scenario where one has set up
ranges etc. are more dependent on the part being played than on the
instrument. You might want to try out how different instruments sound for
the part, without having to reset the controllers just because you loaded
an "xiy" instrument.
Regarding compatibility: although I seldom use Zyn these days, I do use
the same bank directories between the two. If I create an instrument and
it is saved as an xiy, Zyn will ignore it due to the file extension. If
the proposed .xiy just contains the same xml structure as the xiz, with
an added element containing the additional controller settings, the
content will be backwards-compatible with Zyn (which will just ignore
the parts of the xml it's not using). Just adding a yoshimi namespace
(or prefixing the names) to the additional data and checking for the
existence of the element when reading the file should be enough to
maintain compatibility and avoid potential future naming conflicts.
It makes sense in my head, but I think Will mentioned a reason why this
was undesirable or difficult. I forget what it was. Will, care to
comment? :-)
The potential issue I can see is if Zyn in the future decides to add
similar functionality, leading to annoyances. There is also the possible
issue of users expecting xiz-files saved in yoshimi to function exactly the
same in Zyn (including controller settings). Then the question is if it is
better to have a Zyn instrument resaved with controllers "disappear" from
Zyn or to have it remain with possible confusion about the contents.
I suppose the summary of options are:
1) Retain .xiz-extension -- potential user confusion about instrument
capabilites in Zyn/Yoshi
2) Replace file X.xiz with X.xiy -- instrument no longer shows up in Zyn if
banks are shared
3) Save X.xiy alongside X.xiz, prioritize xiy -- instrument still shows up
in Zyn, but introduces tons of problems with cross-editing etc.
At the end of the day, if a user wants to use an xiy-instrument in Zyn I
suppose they would only have to change the file extension. Might be a
non-issue for most.
One of my particular concerns is protecting users against accidentally saving
this as an ordinary instrument and thus losing their settings. I don't ever
use
Zyn these days, but I can well imagine others might, so do this simply by
saving there. The obvious answer would be to talk to the Zyn people and try
and
get them interested, but I've done that a number of times in the past and got
nowhere.
However, we could still make this an .xiz if people don't think that's an
issue. In a patchset, the controller data is already *after* the instrument
data, and there are only a few individual extras we'd be putting in
beforehand.
None of these require an extra branch so there would be nothing for Zyn or
older Yoshi to choke on.
Whichever way we go I'd be inclined to insert an extra statement in either the
INFO section of the file, or BASE_PARAMERS indicating that it's an extended
instrument.
In the part instrument name, the mixer window and instrument banks, I think
the
best thing to do is change the text colour to (say) a very strong blue so it's
pretty obvious. It might be possible to add something in the tooltip too.
For all saving I'd suggest everything as normal until the last minute, then a
pop-up asking if you want to include part settings.
The risky one is loading. We can have the same query and if you elect to have
just the basic instrument, then that's when you could forget and accidentally
lose settings. However, a possible way round that would be to store the fact
that it was originally an extended type, and give a warning when trying to
resave.
Finally, there can be a switch in Settings...Switches to enable extended
types.
This would default to off - i.e. the current situation. However, we'd still
store the fact that an extended instrument had been loaded, and though we
wouldn't normally ask when resaving, we would warn that the original file was
extended in this case.
As an exception, in patchsets and states I think the extended type should
always
be saved and loaded silently regardless. Effectively, this already happens
anyway!
P.S.
I originally placed Humanise in the part edit window because at the time I
wasn't sure whether it should be an instrument setting or a part one. Also the
main part section is already pretty tightly packed! Ultimately I think I made
the wrong decision by fixing it as a part one, and should have made it an
instrument setting - even though I was even more reluctant to make changes
than I am now. It works particularly well on non-fret stringed and horn
sounds.
