Re: [Jsynthlib-devel] synth support that's not made it into SVN!!

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

On 9/14/2011 2:19 PM, Frankie Fisher wrote:
> I have been looking at doing a driver for the Roland U220 at the 
> moment and that uses the same memory-mapped bulk data transfer as the 
> MT32, I wonder if there is scope for commonality between some of the 
> Roland drivers.

I think I put that idea forward a long time ago; the idea of having 
common methods for a whole manufacturer, since a manufacturer will often 
use certain data encoding methods in several synths. So, we could have a 
bunch of general Roland routines in synthdrivers.Roland and then the 
individual synths could be below that (like synthdrivers.Roland.BS420).

The general consensus, as I recall, was "don't do that". For starters, 
it creates interdependency between synthdrivers (ie, it would break the 
possibility of having plugable/modularized synthdrivers). The other fear 
was this. Suppose that Roland comes out with some synth, the BFD-100. 
Someone makes a synthdriver for it, along with some data decoding 
routines in the "common" Roland section.

Then, Roland comes out with another synth, the BFD-200, and someone else 
starts writing a synthdriver for *that*. Let's say that the data 
encoding in the BFD-200 is just a *little* different, such that the 
author of the BFD-200 synthdriver thinks that the *first* author made a 
slight mistake in the common code (and the second author doesn't know 
the specifics of the BFD-100, so they really don't know) and they change 
it to work properly for this BFD-200. This could break the BFD-100 driver.

Of course, that doesn't stop you from just copying some code from other 
Roland drivers. The downside is that, if a actual bug *is* found in 
either copy, there's little likelihood that the person who fixes it will 
know to go fix it in the other drivers.

- Joe