Re: [Jsynthlib-devel] XML patch saving....

[Rib R. <ri...@gm...>]

On 3/9/06, Joe Emenaker <jo...@em...> wrote:
> Rib Rdb wrote:
> > On 3/9/06, Joe Emenaker <jo...@em...> wrote:
> >
> >> Rib Rdb wrote:
> >>
> >>> The main reason IPatch was created was
> >>> so people don't have to subclass Patch.
> >>>
> >> "so people don't have to" make use of the existing code in Patch and,
> >> instead, have to write every method anew? Well, we shouldn't dwell on
> >> "how come it wasn't done *this* way?" stuff.
> >>
> >
> > "so people don't have to" be restricted by the design of the Patch clas=
s.
> >
> Well, I think Patch should have been a fairly minimal abstract class,
> and then SinglePatch and BankPatch would be subclasses of those with the
> Single- and Bank-specific methods... but I wasn't around when those
> decisions were made, and what's done is done. I'm just saying that there
> was a way to do it that didn't require every new type of patch to have
> to redefine all of the methods *and* which wouldn't overly restrict
> those new types of patches.
> >> This would allow us to change the format, or to
> >> support various formats. Even if we never decided to change the *file*
> >> format again, we could still use the PropertyHolder idea to support
> >> other formats for other purposes.... like transmission over the net or
> >> copy/paste or something like that.
> >>
> >
> > I guess I just prefer the extreme programming approach.  Why make it
> > more complicated now to support something that we might possibly want
> > to use at some point in the future.  I'd rather keep the design simple
> > now, and then when it needs to change, find the best design for the
> > new requirements.
> Well, that's how we got what we have now. Putting everything in core.*
> was a simple design that worked... until things started getting big. The
> current midi layer was a simple design that worked... until multiple
> things (like the midi monitor) needed to be notified of the same sysex
> messages. Now we have a half-dozen logging methods in MidiUtil and
> Actions all feeding into MidiMonitor, and they're getting called from a
> half-dozen other methods in PatchEdit and MidiUtil.
>
> Temporary fixes turn into permanent ones. Simple "just for now"
> solutions get appended to until they're unruly and unmanageable. So, the
> best way to save yourself grief down the road is to make sure that you
> design something now that isn't too complicated to use today, yet
> flexible to accommodate all the stuff you can imagine needing in the futu=
re.
> > But whatever.  I don't have time to write a new
> > parser and XML writer.  If you do, go right ahead.
> >
> I have time to write the parser and the XML writer.... and I can write
> the PropertyHolder or whatever we want to call it. All you'd need to do
> is support a read(PropertyHolder) and write(PropertyHolder) for any
> given patch in your XMLDriver code.

I shouild be able to do that.