Re: [Jsynthlib-devel] Okay... so why can't I edit a patch with this?

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

Brian wrote:

>>
>> Do you know of any technical barrier to putting all of the various 
>> checksum algorithms into one class, so that something like the 
>> hypothetical EvenMoreConformingDriver could use something like:
>>   setChecksumType(YAMAHA_PRE_1996);
>> in the constructor? I didn't say *psychological* barriers.... I said 
>> *technical*. :)
>
> No. I think that would be a good idea if someone is willing to put in 
> the time. The only barrier is how to get people to know which checksum 
> to use.

Well, there'd have to be some copious comments with each method in the 
class explaining exactly what each one does. Actually, I was 
contemplating the same kind of thing for devices that need to do some 
kind of 7-bit-to-8-bit conversion, like with Alesis stuff. Take a look 
at Zellyn's AlesisQS SysexRoutines.java and you can see the kind of 
explicit commenting I'm thinking of:
http://cvs.sourceforge.net/viewcvs.py/jsynthlib/JSynthLib/synthdrivers/AlesisQS/SysexRoutines.java?view=markup

Additionally... has there been any talk about having a Wiki for 
describing how drivers interact with JSL?

> But if you know the different checksum types in use and how to name 
> them such that people will know which one to pick, please do. The 
> major problem I've had so far is that most manuals don't say "We use 
> the foo algorithm" for checksumming, they usually just give the step 
> by step algorithm. From a driver writers pov, I've found it easier 
> just to take this algorithm from the manual and type it in for each 
> driver, than to check all the other drivers already written and try to 
> figure which one is doing the same thing. If the checksum algorithms 
> can really be boiled down to things like YAMAHA_PRE_1996, than that 
> would be great.

Well, you've seen more checksum algorithms than I have, so you're a 
better judge of whether they tend to remain the same on a 
per-manufacturer basis. I'm *hoping* that there's some sense of sanity 
to the grouping... such that we could put in the comments (or a Wiki):

    /**
    * GENERIC - This is the most common checksum type. It adds up blah
    blah blah and appends it to location XYZ.
    * NONE - This calculates no checksum and doesn't add any bytes to
    the message
    * BOSS_DR - Most Boss and Roland drum machines use this one. It
    calculcates it like... blah blah blah.
    */

Along with that, should be a section listing manufacturers, so that a 
new developer doesn't have to read the explanation of each checksum type:

    /**
    * Alesis - Most use GENERIC. A few of their XJUE-series synths use
    the YAMAHA_PRE_1996 style
    * Boss - Most use NONE, but their drum machines use BOSS_DR
    *...

Even if this info isn't completely thorough, it should be easy enough 
for a developer to just *try* a few likely candidates. In fact.... I 
think that it's entirely possible to write a method which, given a 
known-good (ie, received as a patch dump) patch, tests it against all 
current checksum methods and reports back which methods the patch works 
with.

> Please note also that there is ongoing work to allow future drivers to 
> be written as XML files which describe the device rather than having 
> to write everything in java.

I know. I've been having a good conversation with Rib Rdb about 
better-integrating the XML driver into devicesConfig.

> If we are going to add some niceties to the driver writing process it 
> might be worthwhile to see how the niceties could be carried over such 
> that they are available to XML drivers as well.

Actually, in order to do this, it would also make it really easy to make 
a "tellMeWhatChecksumsWorkWithThisPatch" method. So, we'd kill two birds 
with one stone.

- Joe