Re: [Jsynthlib-devel] test refactor branch

[Frankie F. <jsy...@te...>]

On 29/12/2011 11:29, Martin Tarenskeen wrote:
>
>
> On Thu, 29 Dec 2011, Frankie Fisher wrote:
>
>> However I don't have any of the other synths so its not really
>> possible for me to do this for any of the other devices as its
>> impossible for me to test it. Whereas if there was a universal driver,
>> the remote control stuff that I had done for TX81z might transfer over
>> to other synths for free (depending how the menus are set up). Plus, if
>> someone reports a bug on e.g. the WT11, then maybe the bug is also
>> reproducible on the TX81z which would mean it could be fixed on the
>> TX81z as well.
>
> VMEM sysex bulk dump compatibility was the easy part when I developed
> the Atari program "YSEDITOR PLUS" in the 1990's. Supporting the
> 100-patch bankformat (actually via MIDI 128=4x32 patches) was already
> a bit more complicated. But supporting all these different voice
> editbuffer formats and different remote control messages in one
> program was a real nightmare. (at the end of it YSEDITOR did a pretty
> good job). It is true, many of the problems I had could only be solved
> because several people and the local music shop were willing to let me
> do some testing with some of these Yamaha synths at home. I have owned
> a YS200 and V50, I was able to do some testing with a TX81Z, DS55,
> WT11, and got help and feedback from people using some of the other
> synths, and I had all the SysEx specs. On paper - it was the time
> before everyone could download all manuals as PDF from the internet :-)
>
> I don't have much time and never learned to code in Java, but the
> know-how I aqcuired when creating YSEDITOR (I still have the GFA basic
> source code) could be helpful when developing a universal 4-op FM JSL
> driver.
>

The existing drivers might already have code that converts from VMEM to
VCED etc format for sending individual patches, so maybe it wouldn't be
that hard to create the specific code for each device.

What about the patch editors though? Are there any different parameters
in each group? Or are they all pretty much the same in that regard?
Would you want to be able to edit parameters that didn't apply to the
TX81z? Probably not cos it would be confusing. It wouldn't be hard to
disable certain controls based on which device the driver was handling.

Are the performances common across each device as well? I've started
doing some work with the performances on the TX81z with the eventual
plan of making an editor for them. In fact I wonder what you think is
the best solution to the problem I am having. The performances refer to
up to iirc 8 patches (and a few other params). These are referenced by
save slot e.g. I12. If you dump the performance bank, then change the
patches, the performance might not make any sense any more. So it seems
like there are a few ways to do this:
1) don't do anything clever with the performance editor - just make it
dump and save banks (or individual performances via remote control if
necessary), and rely on the user to keep the same patches in the user bank
2) when dumping the performances also dump the user bank, and when
sending a performance or performance bank to the device send the user
bank as well
3) try and be clever, and when sending/receiving a performance, also
send/receive any patches that the performance references as well

I guess to do 2 or 3, JSL would have to store a performance dump
followed by a user bank dump. But JSL doesn't really have a good
mechanism for multi stage dumps (send a message, await some data, then
send a different request, then wait for the second set of data). I have
seen some drivers that attempt to deal with this kind of thing by
putting delays into it, but they're basically putting delays into the UI
thread which is a disaster. This is sometime I need to sort out before I
write the P2k series driver, as that family has quite large dumps so
sending/receiving needs to be implemented using flow control really for
best results.

Maybe the bit of code that listens for data after initiating a dump
needs to be extended so that flow control can do things conditionally
e.g. re-request a section if the checksum didn't add up. I guess each
driver should be able to provide its own "sysex listener" that can
filter out extraneous sysex (e.g. the stuff that's sometimes generated
as a sideeffect of using the remote control functionality), and be able
to control the flow of the dump.

well that's enough rambling for one message!

frankie