jsynthlib-devel — Mailing list for developers and users interested in improving the JSynthLib.

Re: [Jsynthlib-devel] test refactor branch

[Martin T. <m.t...@zo...>]

On Thu, 29 Dec 2011, Frankie Fisher wrote:

>> 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.
True. But DX11 ACED2, V50 ACED3, YS200 EFEDS, and DS55 DELAY are not yet 
supported.

> 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?

VCED parameters: same for all models, with a few exceptions (e.g. DX21 
stereo chorus)
ACED parameters: not available on DX100/27/21
ACED2 parameters: not available on DX100/27/21, TX81z
ACED3 parameters: V50 only, DSP FX parameters 
EFEDS parameters: YS200/YS100/B200/TQ5 only, DSP FX parameters
DELAY paramaters: a simple digital delay with only 2 parameters (ON/OFF, 
LONG/SHORT) available only on the DS55.

> 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.

I think we could have several different drivers, but they could share the 
same patch/bank/library format and a lot of common source code. Maybe it 
is possible to disable those parameters that are not supported by a 
selected synth type, but still keep the edit parameters visible, maybe 
grey colored ?

> Are the performances common across each device as well?

I am afraid not. The DX100/DX21/27 are not multitimbral. I don't know how 
much the DX11 and TX81Z are similar. The V50 and is probably more 
complex. This model even has a bank memory for 100 performances.

I have to take a look in my old YSEDITOR source code and the SysEx specs. 
But if I remember correctly I had to write different code for the TX81Z 
performances and for for example the YS200 performances. The performances 
look very similar (8 parts, each with things like volume, pan, patch 
number, note-limit H/L, etc.) but the sysex code is not compatible. But as 
I said, I have to look into that to be sure.

-- 

MT

Re: [Jsynthlib-devel] test refactor branch

[John M. <jo...@as...>]

FWIW, the 'performances' you describe them sound vaguely similar to Kawai K4 Multi Banks. They're basically a set of patches that define some general features such as volume, keyboard split etc then references up to 8 other patches that control the actual sounds produced. It sounds like the same sort of issue with them in that, if you move patches around in the 'single' banks, the 'multi' patch will be pointing at the wrong place.

It's a big issue from an editing point of view because you probably ought to get user confirmation if you try to do anything clever and the fact the single a.d multi/performance banks are separate makes them inter-dependant in a bad way.

Before I discovered JSynthLib, when I was thinking of writing a K1 editor on my own (similar structure to K4) this was something that held me back because I thought long about it without coming to a conclusion and it seemed like that decision could be important to the architecture of the application.

John
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Frankie Fisher <jsy...@te...> wrote:

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

_____________________________________________

Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_____________________________________________

Jsynthlib-devel mailing list
Jsy...@li...
https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel

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

Re: [Jsynthlib-devel] test refactor branch

[Chris W. <chr...@ch...>]

Martin Tarenskeen said on 29/12/11 09:43:
>
>
> On Thu, 29 Dec 2011, Chris Wareham wrote:
>
>> I've commited a change to the AbstractLibraryFrame and Patch classes in
>> order to handle conversion from core.Patch to org.jsynthlib.core.Patch.
>> The patches seem to load and are being identified as Yamaha patches,
>> but not specifically TX81Z ones. I'll test with the trunk version of
>> JSynthLib to see if this is the same behaviour there, and if not I'll
>> work out why tomorrow.
>
> I tested your latest version, and on my system the patches are loaded
> and identified as TX81Z patches perfectly.
>

I'd forgtotten to add the TX81Z driver via the preferences panel - once 
I'd done that the library patcehs were identified as TX81Z patches 
rather than just generic Yamaha ones. It would be nice if JSL loaded the 
correct driver on demand, something for a wish list perhaps.

OK, seeing as it doesn't look like I've broken support for existing 
synths, I'll now try and complete support for the Cheetah MS6. As 
Frankie Fisher mentioned in another mail, it's quite difficult to test 
without a supported device! Not sure whether this is something that 
could be mocked with JMock or Mockito, but it would be very useful.

Chris

Re: [Jsynthlib-devel] test refactor branch

[Martin T. <m.t...@zo...>]

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.

-- 

MT

Re: [Jsynthlib-devel] test refactor branch

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

On 29/12/2011 09:37, Martin Tarenskeen wrote:
> I am not completely happy with the TX81Z and DX100 drivers anyway. In the 
> (I hope not too far) future I hope to be able to develop drivers 
> that should work on the complete TX81Z "compatible" 4-op FM synths:
>
> A driver to support: DX21/27/100, DX11, TX81Z, WT11
>
> A driver to support: YS100/200/B200/TQ5, V50, and DS55
>
> The problem is: All these synths use the same SysEx bank format (32 
> patches) but bytes that are described as "usused" or "reserved" in the 
> SysEx specs for one synth but are really used for new parameters in 
> another synth. This should not be a big problem. Such parameters will not 
> be recognized by some synths, but the JSynthLib drivers should be careful 
> not to overwrite such "unused" parameter addresses with NULL values. (I 
> have not checked yet what the current TX81Z and DX100 drivers do). For 
> example it should be possible to load and save a TX81Z patch or bank in a 
> DX21 ignoring the TX81Z additional parameters, but without loosing them.
>
> This is perfectly possible to handle when using the bank format (VMEM), 
> but is a problem for separate patches: There are SIX different SysEx data 
> formats for this: VCED (all models), ACED (TX81Z and newer), ACED2 (DX11, 
> V50), ACED3 (V50), EFEDS (YS100/200/B200/TQ5), DLY (DS55).
>
> Therefore, in my opinion, a "universal" driver for Yamaha 4-op FM synths 
> should store patches and banks in the compressed VMEM bankformat (128 
> bytes of data for one patch) even when storing individual patches. Only 
> when sending single patches to the synth this should be converted to 
> VCED/ACED/etc. sysex editbuffer format.
>
> Such a driver would be usable on a complete family of Yamaha synths!
>

That might work quite nicely. I have done a partial implementation of
remote control stuff to get at individual patches and banks of the
TX81z. 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.

One of the problems for JSL that I have been pondering is how can you
verify a driver still works if you don't have access to the synth - a
salient point given the two refactoring efforts in progress. One
approach might be to write some kind of test stubs that
emulates/verifies a synth's sysex implementation. But if one driver
supports several similar synths you can test 90% of the driver on the
synth you happen to have. Though you still end up needing access to the
synth to test the last 10% that might be specific to that one synth.

frankie

Re: [Jsynthlib-devel] test refactor branch

[Martin T. <m.t...@zo...>]

On Thu, 29 Dec 2011, Chris Wareham wrote:

> I've commited a change to the AbstractLibraryFrame and Patch classes in
> order to handle conversion from core.Patch to org.jsynthlib.core.Patch.
> The patches seem to load and are being identified as Yamaha patches,
> but not specifically TX81Z ones. I'll test with the trunk version of
> JSynthLib to see if this is the same behaviour there, and if not I'll
> work out why tomorrow.

I tested your latest version, and on my system the patches are loaded and 
identified as TX81Z patches perfectly.

-- 

MT

Re: [Jsynthlib-devel] test refactor branch

[Martin T. <m.t...@zo...>]

On Thu, 29 Dec 2011, Chris Wareham wrote:

> Martin Tarenskeen said on 28/12/11 22:42:
>> 
>> Hi Chris,
>> 
>> I'm attaching the patchlib file I am using for testing.
>> 
>
> Hi Martin,
>
> I've commited a change to the AbstractLibraryFrame and Patch classes in
> order to handle conversion from core.Patch to org.jsynthlib.core.Patch.
> The patches seem to load and are being identified as Yamaha patches,
> but not specifically TX81Z ones. I'll test with the trunk version of
> JSynthLib to see if this is the same behaviour there, and if not I'll
> work out why tomorrow.

I am not completely happy with the TX81Z and DX100 drivers anyway. In the 
(I hope not too far) future I hope to be able to develop drivers 
that should work on the complete TX81Z "compatible" 4-op FM synths:

A driver to support: DX21/27/100, DX11, TX81Z, WT11

A driver to support: YS100/200/B200/TQ5, V50, and DS55

The problem is: All these synths use the same SysEx bank format (32 
patches) but bytes that are described as "usused" or "reserved" in the 
SysEx specs for one synth but are really used for new parameters in 
another synth. This should not be a big problem. Such parameters will not 
be recognized by some synths, but the JSynthLib drivers should be careful 
not to overwrite such "unused" parameter addresses with NULL values. (I 
have not checked yet what the current TX81Z and DX100 drivers do). For 
example it should be possible to load and save a TX81Z patch or bank in a 
DX21 ignoring the TX81Z additional parameters, but without loosing them.

This is perfectly possible to handle when using the bank format (VMEM), 
but is a problem for separate patches: There are SIX different SysEx data 
formats for this: VCED (all models), ACED (TX81Z and newer), ACED2 (DX11, 
V50), ACED3 (V50), EFEDS (YS100/200/B200/TQ5), DLY (DS55).

Therefore, in my opinion, a "universal" driver for Yamaha 4-op FM synths 
should store patches and banks in the compressed VMEM bankformat (128 
bytes of data for one patch) even when storing individual patches. Only 
when sending single patches to the synth this should be converted to 
VCED/ACED/etc. sysex editbuffer format.

Such a driver would be usable on a complete family of Yamaha synths!

-- 

MT

Re: [Jsynthlib-devel] test refactor branch

[Chris W. <chr...@ch...>]

Martin Tarenskeen said on 28/12/11 22:42:
>
> Hi Chris,
>
> I'm attaching the patchlib file I am using for testing.
>

Hi Martin,

I've commited a change to the AbstractLibraryFrame and Patch classes in
order to handle conversion from core.Patch to org.jsynthlib.core.Patch.
The patches seem to load and are being identified as Yamaha patches,
but not specifically TX81Z ones. I'll test with the trunk version of
JSynthLib to see if this is the same behaviour there, and if not I'll
work out why tomorrow.

Regards,

Chris

Re: [Jsynthlib-devel] test refactor branch

[Chris W. <chr...@ch...>]

Chris Wareham said on 26/12/11 11:37:
> Martin Tarenskeen said on 26/12/11 08:54:
>>
>> Hi,
>>
>> I'm trying the refactor branch from SVN. I have not done much testing yet
>> but it seems I am getting error messages, and failure, if I try to load a
>> (for example) TX81Z xxx.patchlib from the current trunk in the new
>> refactor version. Creating and then loading a new xxx.patchlib library
>> works fine.
>>
>> Has backward compatibility been broken on purpose ?
>>
>
> Damn, I'd forgotten about one of the changes I'd made - the
> de-serialisation of existing patchlibs wont work, as I converted several
> members from StringBuffers to Strings. I'll write a converter for old
> style patches by implementing a custom deserialisation method and
> checking the sereial version UID. I should get a chance to do it
> tomorrow (Tuesday 27th UK time).
>
> Regards,
>
> Chris
>

Hi Martin,

I've implemented a readObject method in the Patch class, which attempts 
to deserialize bothe the new version of the class and the previous one 
that used StringBuffers for three of the data members.

I have a nasty feeling that this still won't work, as the Patch class 
has also moved from a "core" package to an "org.jsynthlib.core" one, so 
the deserialization may not even get as far as my readObject method.

Relying on serialised objects for long-term persistence, particularly 
when the data isn't held in another form as well (such an RDBMS or flat 
files), is asking for trouble. With JSynthLib in particular, the rather 
messy class hierarchy makes things even worse.

If you could let me have any stack trace from attempting to read a patch 
library, and possibly a copy of the patchlib itself, then that would be 
most helpful for me to try and come up with a solution.

Regards,

Chris

Re: [Jsynthlib-devel] test refactor branch

[Chris W. <chr...@ch...>]

Martin Tarenskeen said on 26/12/11 08:54:
>
> Hi,
>
> I'm trying the refactor branch from SVN. I have not done much testing yet
> but it seems I am getting error messages, and failure, if I try to load a
> (for example) TX81Z xxx.patchlib from the current trunk in the new
> refactor version. Creating and then loading a new xxx.patchlib library
> works fine.
>
> Has backward compatibility been broken on purpose ?
>

Damn, I'd forgotten about one of the changes I'd made - the 
de-serialisation of existing patchlibs wont work, as I converted several 
members from StringBuffers to Strings. I'll write a converter for old 
style patches by implementing a custom deserialisation method and 
checking the sereial version UID. I should get a chance to do it 
tomorrow (Tuesday 27th UK time).

Regards,

Chris

[Jsynthlib-devel] test refactor branch

[Martin T. <m.t...@zo...>]

Hi,

I'm trying the refactor branch from SVN. I have not done much testing yet 
but it seems I am getting error messages, and failure, if I try to load a 
(for example) TX81Z xxx.patchlib from the current trunk in the new 
refactor version. Creating and then loading a new xxx.patchlib library 
works fine.

Has backward compatibility been broken on purpose ?

-- 

MT

Re: [Jsynthlib-devel] Cheetah MS6 support

[<chr...@ch...>]

Martin Tarenskeen said on 23/12/11 08:02:
> 
> I have also tried "ant build" but this gives 41 errors, ending in "BUILD 
> FAILED"
> 

These errors were because of Java 1.7 features I had inadvertently used. I've switched my build environment to use OpenJDK 1.6, and committed the changes necessary to get things working under 1.6.

Regards,

Chris

Re: [Jsynthlib-devel] Cheetah MS6 support

[<chr...@ch...>]

m.t...@zo... wrote:
> 
> 
> I am running Linux Fedora 16
> If you need more info let me know.
> 

I should have mentioned that I am also running Fedora 16 with OpenJDK 7, and I have tested that the application builds and starts on a machine running CentOS 6 with Oracle's JDK.

Regards,

Chris

Re: [Jsynthlib-devel] Cheetah MS6 support

[<chr...@ch...>]

m.t...@zo... wrote:
> 
> On Fri, 23 Dec 2011, Chris Wareham wrote:
> 
> > If anyone has the time, could they please test my branch with their
> > synths that already have support in JSynthLib. It would be useful to
> > know if I have broken anything with my changes, given that I don't have
> > any synths that are already supported.
> 
> I have a downloaded your branch from svn, but don't know the correct 
> command to compile and/or run it. In trunk/JSynthLib I can do "ant 
> build-run" but that fails in branches/refactor and branches/UIrefactor. 
> I have also tried "ant build" but this gives 41 errors, ending in "BUILD 
> FAILED"
> 
> I am running Linux Fedora 16
> If you need more info let me know.
> 

Hi Martin!

Thanks for taking the time to download and test the branch. The ant commands are as follows:

ant build - the default target which compiles and copies files to the build directory

ant run - builds and runs the application

ant dist - builds all the distribution files for a release

There is also an update-drivers target, which rebuilds the synthdrivers.properties file. Since this only needs to be run when a new device is added to the application it is no longer invoked as part of the build or dist targets. The actual class that writes the properties file needs to be amended to cope with the drivers now being in the or.jsynthlib.synthdrivers package, but I haven't done this yet since it's trivial to add a new device to the properties file by hand.

Any further questions, please let me know.

Regards,

Chris

Re: [Jsynthlib-devel] Cheetah MS6 support

[Martin T. <m.t...@zo...>]

On Fri, 23 Dec 2011, Chris Wareham wrote:

> If anyone has the time, could they please test my branch with their
> synths that already have support in JSynthLib. It would be useful to
> know if I have broken anything with my changes, given that I don't have
> any synths that are already supported.

I have a downloaded your branch from svn, but don't know the correct 
command to compile and/or run it. In trunk/JSynthLib I can do "ant 
build-run" but that fails in branches/refactor and branches/UIrefactor. 
I have also tried "ant build" but this gives 41 errors, ending in "BUILD 
FAILED"

I am running Linux Fedora 16
If you need more info let me know.

-- 

MT

[Jsynthlib-devel] Cheetah MS6 support

[Chris W. <chr...@ch...>]

Hi folks!

I order to test the code in my refactoring branch, I've added a single
patch driver for the Cheetah MS6 synthesiser. So far fetching a patch
works fine, so next it's to test writing back to the tone edit buffer
on the synth. I also want to add support, possibly in the MIDI
preferences panel, for setting the MIDI channel used for playing a note.

If anyone has the time, could they please test my branch with their
synths that already have support in JSynthLib. It would be useful to
know if I have broken anything with my changes, given that I don't have
any synths that are already supported.

Regards,

Chris

Re: [Jsynthlib-devel] New refactoring branch

[William Z. <wrz...@po...>]

On Fri, Dec 16, 2011 at 4:16 AM, <chr...@ch...>wrote:

>
> I've committed my working copy as a new branch, as I've been making a
> large number of changes that I didn't want to apply to the trunk without
> approval.
>

Sounds awesome.  You'll definitely want to sync with Joe Emenaker and look
at his branch; it sounds like one of you is going to have to do a bunch of
work to merge the two branches.

-Bill Zwicky

Re: [Jsynthlib-devel] New refactoring branch

[Joachim <li...@sd...>]

Hi Chris,

Joe Emenaker already made a refactoring branch:
branches/UIRefactor

It may be best if you two sync each other.

Joachim

Am 16.12.2011 13:16, schrieb chr...@ch...:
> Hi folks,
>
> I've committed my working copy as a new branch, as I've been making a large number of changes that I didn't want to apply to the trunk without approval. A summary is below.
>
> 1 - Deleted the incomplete code in the existing org.jsynthlib package - I wonder why this was not committed originally to a branch.
> 1 - Moved all remaining source code into a src subdirectory.
> 2 - Moved the core and synthdrivers packages to src/org/jsynthlib/.
> 3 - Deleted Makefiles as maintaining a parallel build system seems pointless since Ant is available on Windows, Mac OS X and other Unix platforms.
> 4 - Deleted the stale META-INF directory that was presumably from a commit of an expanded JAR file of the project.
> 5 - Rewrote the Ant build script and properties file from scratch to match current best practices.
> 6 - Added targets and third party JAR files for the Checkstyle and PMD code analysis tools.
> 7 - Made a huge number of changes to the core and synthdrivers code, see below.
>
> The code changes I have made started with an attempt to remove a lone setter from the Device interface. It required changes to all the synth driver device classes, as the device is now a constructor argument for devices since it should be initialised once. While looking through the synth drivers I noticed a lot of either cut and paste code or else cargo cult programming. A typical example is the setPatchName methods, where a byte array was being allocated then immediately derefernced and a StringBuilder was then being initialised with a string but immediately having toString called on it as part of a return statement.
>
> Overall, I think the code can be refactored into something clean and elegant in a top down manner. This should result in no casts if the inheritance hierarchy is cleaned up, better encapsulation and a removal of Swing code from drivers that would facilitate a move to unit testing. A lot of code duplication in the synth drivers could be removed with careful refactoring, making the job of writing new drivers much easier. Sorting out the inheritance hierarchy will be my next project, and I'll try to improve encapsulation as I go since far too many data members are public or package-private, expose modifiable Collections or pass around array references in ways that introduce fragility.
>
> Regards,
>
> Chris
>
>
>
> ------------------------------------------------------------------------------
> Learn Windows Azure Live!  Tuesday, Dec 13, 2011
> Microsoft is holding a special Learn Windows Azure training event for
> developers. It will provide a great way to learn Windows Azure and what it
> provides. You can attend the event by watching it streamed LIVE online.
> Learn more at http://p.sf.net/sfu/ms-windowsazure
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>

[Jsynthlib-devel] New refactoring branch

[<chr...@ch...>]

Hi folks,

I've committed my working copy as a new branch, as I've been making a large number of changes that I didn't want to apply to the trunk without approval. A summary is below.

1 - Deleted the incomplete code in the existing org.jsynthlib package - I wonder why this was not committed originally to a branch.
1 - Moved all remaining source code into a src subdirectory.
2 - Moved the core and synthdrivers packages to src/org/jsynthlib/.
3 - Deleted Makefiles as maintaining a parallel build system seems pointless since Ant is available on Windows, Mac OS X and other Unix platforms.
4 - Deleted the stale META-INF directory that was presumably from a commit of an expanded JAR file of the project.
5 - Rewrote the Ant build script and properties file from scratch to match current best practices.
6 - Added targets and third party JAR files for the Checkstyle and PMD code analysis tools.
7 - Made a huge number of changes to the core and synthdrivers code, see below.

The code changes I have made started with an attempt to remove a lone setter from the Device interface. It required changes to all the synth driver device classes, as the device is now a constructor argument for devices since it should be initialised once. While looking through the synth drivers I noticed a lot of either cut and paste code or else cargo cult programming. A typical example is the setPatchName methods, where a byte array was being allocated then immediately derefernced and a StringBuilder was then being initialised with a string but immediately having toString called on it as part of a return statement.

Overall, I think the code can be refactored into something clean and elegant in a top down manner. This should result in no casts if the inheritance hierarchy is cleaned up, better encapsulation and a removal of Swing code from drivers that would facilitate a move to unit testing. A lot of code duplication in the synth drivers could be removed with careful refactoring, making the job of writing new drivers much easier. Sorting out the inheritance hierarchy will be my next project, and I'll try to improve encapsulation as I go since far too many data members are public or package-private, expose modifiable Collections or pass around array references in ways that introduce fragility.

Regards,

Chris

Re: [Jsynthlib-devel] Looking for Kawai K1 advice or pointers

[William Z. <wrz...@po...>]

On Wed, Dec 7, 2011 at 2:21 PM, John McCabe <jo...@as...> wrote:

> 2) would you treat the 'pair' of banks as one, in which case, you'd need
> to send and receive two separate sysex messages to download the data, or
> treat them as separate bank?

This is really a question of how people use the synth.  You'll need to
determine if it makes more sense *to a user of the synth* to manage the
K1's patches as two banks or as one.  This might mean the K1 code will be
different from the K4 code, but if it makes more sense for the synth, then
you should do it that way.

-Bill Zwicky

Re: [Jsynthlib-devel] Looking for Kawai K1 advice or pointers

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

On 07/12/2011 22:21, John McCabe wrote:
>
> 2) would you treat the 'pair' of banks as one, in which case, you'd need 
> to send and receive two separate sysex messages to download the data, or 
> treat them as separate bank?
>

It sounds like 2 banks might be the more convenient way to treat it,
although it could probably work either way.

frankie

[Jsynthlib-devel] Looking for Kawai K1 advice or pointers

[John M. <jo...@as...>]

Guys,

I haven't got very far with the K1 driver. I'm having a bit of a dilemma 
and wondered if anyone could point me to any other synths that have a 
similar bank/patch structure as the k1.

I know the K1 is a bit like the K4 but there's a difference; as I 
understand it they both have 64 'single' patches and 32 'multi' patches, 
but the K4's single patches seem to be in one block, e.g. A-1..D-16, 
whereas the K1 has them split in to two blocks; A-1..D-8 and a-1..d-8. 
The patch numbers in the single blocks go:

A-1 = 0
..
D-8 = 31
a-1 = 32
..
d-8 = 63

Unfortunately though a "ALL SINGLE DATA DUMP" sysex message contains 
either A-1..D-8 or a-1..d-8.

So I guess my questions are:

1) are there any other synths you know of with this kind of structure 
that I could use as a template

2) would you treat the 'pair' of banks as one, in which case, you'd need 
to send and receive two separate sysex messages to download the data, or 
treat them as separate bank?

Hope I'm not confusing you too much; I'd better stop there as I'm 
confusing myself a bit!:-)

Thanks for listening.
John

Re: [Jsynthlib-devel] Modifications to the AppConfig class and preferences GUI

[Chris W. <chr...@ch...>]

Joe Emenaker said on 06/12/11 16:17:
> On 12/5/2011 12:36 PM, Chris Wareham wrote:
>> It looks like there was an intention at some
>> point to make the preferences panels embeddable in other dialogs, but
>> this doesn't seem to have come to pass, and the result is a lot of dead
>> code paths.
>
> That was possibly my doing. I think the point was that there would
> sometimes be the desire to take the user directly to the settings for
> something if they needed fixing immediately (for example, if none of the
> available MIDI interfaces were selected, we could pop up the MIDI config
> page).
>
> I recall the code for the individual panels being modular (ie, an "init"
> method and maybe a "show" method or whatnot), but I'm not sure what dead
> code paths you're speaking of...
>
> - Joe
>

Hi Joe!

I'm taking a "top down" journey through the code, and one of the first 
things I hit was in the PrefsDialog class where there's different code 
paths depending on whether zero, one or many preferences panels would be 
available. In my working copy I've removed that chunk of code and all 
the preference panels are added to a tabbed pane (the "many panels" code 
path in the original).

I've been tinkering with more of the other code this evening, and was 
wondering about some of the XML related device stuff. It appears to be 
incomplete, and spread across both the core package and sub-packages of 
the org.jsynthlib package. If I'm reading it right, it seems to be much 
more complicated than the properties based approach that the rest of the 
code uses.

There are also a number of classes in the core package that are unused:

core/Storable.java
core/Storage.java
core/SysexMatcher.java
core/VertScrollBarLookupWidget.java

Adding generics to a few places also highlighted an issue with the 
SceneListModel in the SceneFrame class. It extends PatchTableModel from 
the AbstractLibraryFrame, but is actually a table model for scene 
objects rather than patch ones. I have worked around this, but I'd be 
keen to restructure this code a little better.

Regards,

Chris

Re: [Jsynthlib-devel] Modifications to the AppConfig class and preferences GUI

[Joe E. <jo...@em...>]

On 12/5/2011 12:36 PM, Chris Wareham wrote:
> It looks like there was an intention at some
> point to make the preferences panels embeddable in other dialogs, but
> this doesn't seem to have come to pass, and the result is a lot of dead
> code paths.

That was possibly my doing. I think the point was that there would 
sometimes be the desire to take the user directly to the settings for 
something if they needed fixing immediately (for example, if none of the 
available MIDI interfaces were selected, we could pop up the MIDI config 
page).

I recall the code for the individual panels being modular (ie, an "init" 
method and maybe a "show" method or whatnot), but I'm not sure what dead 
code paths you're speaking of...

- Joe