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

Re: [Jsynthlib-devel] The addWidget(...) design

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

Joe Emenaker wrote:

> If it's well-received, then I can go make some small changes in the 
> widgets and param-models and then move on with my driver. If it's 
> *not* well-received, then I'm going to have to sub-class every widget 
> and param-model that I want to use so that it works with my data-model 
> design that I'm using for my driver.

Ah, I just thought that was one of your many proposals.  I don't 
understand your complaint though; you never need to subclass widgets, 
and you need to write lots of IParamModel classes anyway.

Since you want to decode and encode your sysex all at once, you need to 
extend IPatch, not Patch.  You can then hide your byte array, and 
require all access to go through getByte, getInt, etc.  I believe Driver 
is the place where you'd instantiate your new patch class.

You're other suggestion make for an interesting new design (and I'm 
guessing the XML package is going that way) but aren't critical to your 
current driver.

-Bill

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

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

Joe Emenaker wrote:

> We have only about 100 synthdrivers and it takes me close to 1 minute 
> to do a CVS update.

Do like I do:  Start the update, then go read e-mail.  This really isn't 
a problem we should worry about.

-Bill

Re: [Jsynthlib-devel] Question for Hex/Bin wizards

[Steven S. <ste...@co...>]

Joe Emenaker wrote:

> Steven Schmidt wrote:
>
>> Given the following specification, what value would you find in the 
>> two bytes 230 and 231  for HI SAMPLE NO: 306 (decimal)?
>> 230 - bit 7  HI START OFFSET  0:OFF, 1:ON
>> 230 - bit 6 HI REVERSE 0:OFF, 1:ON
>> 230 - bit 0-6  HI SAMPLE NO.(MSB) 00~~03E7 : 00~~999
>> 231  HI SAMPLE NO.(LSB)
>
>
> 306 decimal is binary 100110010
>
> I don't know what your HI START OFFSET and HI REVERSE bits are 
> supposed to be. 

sadly, neither do I.

> Also, the spec makes reference to a bit #7 *and* a bit #0, which makes 
> me think that your patch data uses 8-bit bytes. If that true, then 
> your bits arrange themselves as: 

I thought it odd that the spec referred to both bit 6 *and* bits 0-6 for 
the same byte, but that is what it said.  This thing must have been 
updated since the spec that Korg put on its web site, because I would 
expect to find a 0x32 sitting next to a 0x?1 or 0x?2, but this is not 
the case, so - back to the drawing board, or debugger.  Thanks for doing 
the math Joe - I'm still confused but at least I have an idea where I'm 
going.
-Steve

Re: [Jsynthlib-devel] Question for Hex/Bin wizards

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

Steven Schmidt wrote:

> Given the following specification, what value would you find in the 
> two bytes 230 and 231  for HI SAMPLE NO: 306 (decimal)?
> 230 - bit 7  HI START OFFSET  0:OFF, 1:ON
> 230 - bit 6 HI REVERSE 0:OFF, 1:ON
> 230 - bit 0-6  HI SAMPLE NO.(MSB) 00~~03E7 : 00~~999
> 231  HI SAMPLE NO.(LSB)

306 decimal is binary 100110010

I don't know what your HI START OFFSET and HI REVERSE bits are supposed 
to be. Also, the spec makes reference to a bit #7 *and* a bit #0, which 
makes me think that your patch data uses 8-bit bytes. If that true, then 
your bits arrange themselves as:

   ??000001 00110010

Which is 0x?1 0x32

If you made an error when copying the spec to your e-mail... and your 
patch data is actually in 7-bit bytes, then the bits are:

  ??00010 0110010

which would be 0x?2 0x32

- Joe

[Jsynthlib-devel] Question for Hex/Bin wizards

[Steven S. <ste...@co...>]

Given the following specification, what value would you find in the two 
bytes 230 and 231  for HI SAMPLE NO: 306 (decimal)? 

230 - bit 7  HI START OFFSET  0:OFF, 1:ON
230 - bit 6 HI REVERSE 0:OFF, 1:ON
230 - bit 0-6  HI SAMPLE NO.(MSB) 00~~03E7 : 00~~999
231  HI SAMPLE NO.(LSB)

AW: [Jsynthlib-devel] Synth stops responding to dump request

[Joachim B. <jba...@pi...>]

Hello,

it may help to power down the synth, wait a few minutes
and turn it on again.

Sounds like a bug in the synth.

I had such problems with the very buggy Waldorf Microwave XT.

Regards,
Joachim Backhaus

> -----Urspr=FCngliche Nachricht-----
> Von: jsy...@li...
> [mailto:jsy...@li...]Im Auftrag von
> Steven Schmidt
> Gesendet: Freitag, 18. M=E4rz 2005 15:44
> An: jsy...@li...
> Betreff: [Jsynthlib-devel] Synth stops responding to dump request
>=20
>=20
> Anyone had this problem?  Suddenly, my synth is no longer sending the=20
> patch after getting the request.  Worked fine before - I even=20
> reverted=20
> to old code but it still isn't sending.=20
>=20
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from=20
> real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>=20

[Jsynthlib-devel] Synth stops responding to dump request

[Steven S. <ste...@co...>]

Anyone had this problem?  Suddenly, my synth is no longer sending the 
patch after getting the request.  Worked fine before - I even reverted 
to old code but it still isn't sending. 

Re: [Jsynthlib-devel] The addWidget(...) design

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

Rib Rdb wrote:

>On Thu, 17 Mar 2005 14:41:57 -0800, Joe Emenaker <jo...@em...> wrote:
>  
>
>>My hope is that we can reduce the work involved in writing a driver (for
>>synths that don't do crazy stuff in their sysex) so that 90% of the work
>>is just defining the params (ie, location, data type, and name).
>>    
>>
>That's exactly what the XML driver does.  You give some basic
>information (manufacturer, model, etc), specify the type of checksum
>and encoding, then give a list of parameters.
>  
>
Back when the talk of an XML driver first came up, I think I might have 
suggested that the Java-based param/widget infrastructure be set up like 
we're discussing now. If it was done well, then it would allow the XML 
driver to be very *thin*, in the sense that most of the work would just 
be in reading/verifying the XML and then just having a loop read the 
Parameter elements and call some kind of decoder.addParameter for each 
one. It's sounding like that's what you've done...   with the caveat 
that this has not turned into the way things are done when writing 
Java-based drivers as well.

- Joe

Re: [Jsynthlib-devel] The addWidget(...) design

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

Rib Rdb wrote:

>On Thu, 17 Mar 2005 14:51:45 -0800, Joe Emenaker <jo...@em...> wrote:
>  
>
>>Hey.... that's pretty neat!
>>
>>It looks like your "decoder" is what I'm calling a "data-model", no?
>>    
>>
>Yep
>  
>
I'll have to take a look. Is it currently located in the XML stuff? Any 
interest in working it into the core.* stuff?

>>Is it possible to explicitly define the addresses of the params?
>>    
>>
>You can add whatever methods you want to your parameters and/or data model.
>  
>
I guess my question should have been "Is is *already* possible...".

>This could either be required or optional (you only have to use it
>when the value that would be inferred is wrong)
>  
>
That was my thought. For the Boss GT-3, they use the same location for 
different things depending upon other settings. For example, if your 
modulation effect is set to "Chorus", then a certain address might 
contain the chorus regeneration. If the effect is set to "Flanger", then 
the same address might contain the wet mix level. So, you can't just 
start at offset 0 and start enumerating the parameters. For the GT-3, 
you'd have to specify actual addresses. But, even then, you'd only have 
to do it when you needed to jump backward. So, most of the addresses 
could still be inferred.

- Joe

Re: [Jsynthlib-devel] The addWidget(...) design

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

On Thu, 17 Mar 2005 14:41:57 -0800, Joe Emenaker <jo...@em...> wrote:
> Bill Zwicky wrote:
> 
> > Joe Emenaker wrote:
> >
> >> ... addWidget could discover what kind of parameter a ParamModel is
> >> and automatically give it the correct widget (ie, BooleanParamModel
> >> gets a CheckBoxWidget, NumericParamModel might get a spinner,
> >> EnumParamModel would get a ComboBoxWidget, etc).
> >
> > Wow, that would be *really* cool.  I'd love to just whip up a sysex
> > parser, and have the GUI automatically appear.
> 
> My hope is that we can reduce the work involved in writing a driver (for
> synths that don't do crazy stuff in their sysex) so that 90% of the work
> is just defining the params (ie, location, data type, and name).

That's exactly what the XML driver does.  You give some basic
information (manufacturer, model, etc), specify the type of checksum
and encoding, then give a list of parameters.
I thought about automatically generating the editor, but that would
just look ugly.  Instead, I'm working on EditorBuilder.  You load up
the XML driver you wrote, and it gives you a list of parameters. Then
you drag parameters from the list into the editor. By default you get
a combo box for lookup parameters, and a knob for range parameters. 
If you want a different type then you select the parameter and change
the type in the properties window.

That's about all that EB supports at the moment, but I plan to add
support for lots of things including envelopes, scripts (so you can do
things like make the range of one parameter depend on the value of
another), and multiple containers (ie JTabbedPane, or another JSLFrame
that pops up when you click a button).

I think you're right that allowing the user to change the widget types
would mess up the layout. But with the XML driver, you can just create
your own editor in EditorBuilder if you don't like the standard one. 
At one point we talked about supporting multiple editors for a given
patch type, and then allowing the user to choose which to use.

Re: [Jsynthlib-devel] The addWidget(...) design

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

Jeff Weber wrote:

>--- Joe Emenaker <jo...@em...> wrote:
>  
>
>>Well, here's the "grand design" of what I'm thinking
>>of:
>>- Patch data would be given only to one of the items
>>(widget, param-model, or sender) and the others would get it
>>from that.
>>    
>>
>Would it be possible to use a widget with only a
>ParamModel (and no Sender) or with a Sender (and no
>ParamModel) with this design?
>
Well, addWidget already allows you to give it a null in place of a 
sender. So having a ParamModel without a Sender is already possible.

As for having a Sender without a ParamModel.... I don't see why that 
couldn't be allowed. I never envisioned needing that.... but that's not 
a show-stopper.

>I ran into this
>situation with the Behringer FCB1010. The Behringer
>only accepts sysex and does not recognize any
>real-time messages.
>
My Alesis SR-16 drum machine is the same way. If you want to hear the 
patch you're working on, I think you have to send the entire bank back 
as a sysex. I came across something like this when looking at another 
driver, too. I think it was the Alesis DM5. Because the size of the 
entire sysex message was so small, the Sender (instead of sending 
individual changes for individual params) just prepared the entire patch 
and sent it to the edit buffer every time the user changed a param. (On 
a side note, there was probably duplicate code in the Driver for when 
the user explicitly selected "Send". Maybe there should be, if there 
isn't already, a special Sender class that, when a param is modified, 
causes JSL to behave as though the user just selected "Send").

>Is it possible there might be other devices that only accept real-time messages and not sysex?
>  
>
It's possible in that the MIDI spec allows it, I guess. I don't know if 
anything exists that actually does.

However, we could just make the ParamModel classes gracefully handle 
being given a null as the Patch (or my DataModel or Rib Rdb's Decoder), 
yet still allow the Senders to work.

- Joe

Re: [Jsynthlib-devel] The addWidget(...) design

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

On Thu, 17 Mar 2005 14:51:45 -0800, Joe Emenaker <jo...@em...> wrote:
> Rib Rdb wrote:
> 
> >You could do the same type of thing in Java. Then it would look like this:
> >/* when the driver is created */
> >// create params in order so addresses are inferred
> >decoder.addBooleanParam("Midi Pitch Bend");
> >
> >/* Then in the editor */
> >addWidget(leftPane,
> >         new CheckBoxWidget(patch, decoder.getParam("Midi Pitch Bend")),
> >         , 0, 10, 1, 1, -3);
> >
> >
> Hey.... that's pretty neat!
> 
> It looks like your "decoder" is what I'm calling a "data-model", no?

Yep

> Based on that, all we'd have to do is teach addWidget to figure out what
> kind of param it's getting and select the right widget automatically.
> 
> Is it possible to explicitly define the addresses of the params?

You can add whatever methods you want to your parameters and/or data model.
This is supported by the XML driver as well. If your Decoder returns
parameters that have the method setAddress(String), then all of the
parameters accept
<address>0xf00</address>

This could either be required or optional (you only have to use it
when the value that would be inferred is wrong)

Re: [Jsynthlib-devel] explicitly setting start of sysex in send/store patch (Korg)

[Jeff W. <jww...@ya...>]

--- Steven Schmidt <ste...@co...> wrote:
> When I try to store a patch back to the synth - the
> MidiMonitor shows:
> XMIT: Control Change
>   b0 00 00
> XMIT: Control Change
>   b0 20 04
> XMIT: Program Change
>   c0 15
> XMIT: Program Change
>   c0 15
> But never sends a patch.  The debugger showed a
> value of 112 (0x70) in 
> the first Byte, so I explicitly set it to F0 and
> voila - midi monitor 
> does show the patch getting sent.  It still didn't
> save it on the synth, 
> but I'll worry about that later. 
> 
> My question - Should I expect to set the start of
> sysex like that? 
> 
The answer to your first question is, no.

This sounds like the same thing I got caught on. You
need to make sure you have the proper overrides of the
calculateChecksum methods in your driver. If your
patch does not use a checksum, you still need to
override calculateChecksum with a null method. If you
don't do this, the default calculateChecksum will
calculate a value and place it at offset zero of your
sysex record.

See programming.html for details.


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/ 

Re: [Jsynthlib-devel] The addWidget(...) design

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

Rib Rdb wrote:

>You could do the same type of thing in Java. Then it would look like this:
>/* when the driver is created */
>// create params in order so addresses are inferred
>decoder.addBooleanParam("Midi Pitch Bend"); 
>
>/* Then in the editor */
>addWidget(leftPane,
>         new CheckBoxWidget(patch, decoder.getParam("Midi Pitch Bend")),
>         , 0, 10, 1, 1, -3);
>  
>
Hey.... that's pretty neat!

It looks like your "decoder" is what I'm calling a "data-model", no? 
Based on that, all we'd have to do is teach addWidget to figure out what 
kind of param it's getting and select the right widget automatically.

Is it possible to explicitly define the addresses of the params?

- Joe

Re: [Jsynthlib-devel] The addWidget(...) design

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

Bill Zwicky wrote:

> Joe Emenaker wrote:
>
>> ... addWidget could discover what kind of parameter a ParamModel is 
>> and automatically give it the correct widget (ie, BooleanParamModel 
>> gets a CheckBoxWidget, NumericParamModel might get a spinner, 
>> EnumParamModel would get a ComboBoxWidget, etc).
>
> Wow, that would be *really* cool.  I'd love to just whip up a sysex 
> parser, and have the GUI automatically appear.

My hope is that we can reduce the work involved in writing a driver (for 
synths that don't do crazy stuff in their sysex) so that 90% of the work 
is just defining the params (ie, location, data type, and name). Of 
course, there will always be synths that require things to be done the 
old way.

> Making that work for envelopes would be ugly though, expecially since 
> the CZ has a weird envelope.

Not necessarily. Granted, the CZ might have a wierd envelope and you 
might have to create that widget the old way (which you'd always be able 
to do). However, if it was a normal 4-point ADSR envelope, then you 
could just instantiate some EnvelopeParamModel and define where in the 
patch data the four points were stored. The Widget should be able to 
figure out the rest.

> What about when JSL provides multiple widgets for the same data type?  
> i.e. We have both slider and dial widgets for entering numeric values.

There'd definitely still be a way for the programmer to create the 
widget himself and pass it to addWidget if he didn't like the defaults. 
But, if you didn't really care, then you could leave it up to JSL to 
decide what the default boolean widget is, etc. One benefit here is that 
it would allow JSL to let the user change the default widgets. Think of 
Swing's pluggable look-and-feel. JSL could do the same thing, and let 
the user pick between "normal" widgets, or maybe some fancy ones (like a 
boolean widget that looks like an LED light that lights up and turns 
off). Or the user could decide that they wanted knobs instead of sliders 
for numerical params. If they did, then any widgets in drivers which 
were just using the *defaults* would get changed. Drivers which we 
defining their widgets explicitly would be anaffected. Furthermore, I 
don't see any reason why individual editors couldn't choose what 
defaults they wanted so that they didn't have to worry about the user 
changing them, yet could still benefit from the shorthand addWidget() 
method. Of course, there are some serious widget *layout* issues to be 
confronted. Turning all sliders into knobs could really stir up the 
layout of an editor. So, perhaps we'd need to restrict how much freedom 
there was there.... but I think that, overall, something like this would 
be a benefit.

> By the way, are you trying any of this stuff?  (You're writing a 
> driver, right?)  Most of what you propose can actually be inserted 
> into your own class tree, where you can see how well it works.

I've done some of it already. I'm actually at a cross-roads in the 
development of the driver because of the fact that my it (sorry if I 
keep bringing this up) has to convert 7-bit bytes to 8-bit ones and I 
don't want to have each param-model do this individually (which is why 
I'm campaigning for some kind of DataModel or some class to separate 
param-models from the actual Patch object). I want to start moving again 
with development of my driver, which is why I presented my whole idea 
for (what I feel is) an improvement to the param-model/widget system.

If it's well-received, then I can go make some small changes in the 
widgets and param-models and then move on with my driver. If it's *not* 
well-received, then I'm going to have to sub-class every widget and 
param-model that I want to use so that it works with my data-model 
design that I'm using for my driver.

- Joe

[Jsynthlib-devel] explicitly setting start of sysex in send/store patch (Korg)

[Steven S. <ste...@co...>]

When I try to store a patch back to the synth - the MidiMonitor shows:
XMIT: Control Change
  b0 00 00
XMIT: Control Change
  b0 20 04
XMIT: Program Change
  c0 15
XMIT: Program Change
  c0 15
But never sends a patch.  The debugger showed a value of 112 (0x70) in 
the first Byte, so I explicitly set it to F0 and voila - midi monitor 
does show the patch getting sent.  It still didn't save it on the synth, 
but I'll worry about that later. 

My question - Should I expect to set the start of sysex like that? 

Second question -
Another Korg driver (wavestation single patch driver) sends a write 
request in order to store the patch on the synth - I've tried that 
without any success.  Any advice there?  Joachim said he hadn't seen any 
synths that required it, but as I said - Its not saving the patch - with 
or without the write request.
Here's the MidiMonitor output for the changed storePatch with the write 
request:

XMIT: Control Change
  b0 00 00
XMIT: Control Change
  b0 20 04
XMIT: Program Change
  c0 15
XMIT: SysEX:length=627
  f0 42 00 50 4c 08 22 5c 15 46 69 72 .. 00 00 f7
XMIT: Program Change
  c0 15
XMIT: SysEX:length=8
  f0 42 30 50 11 24 15 f7

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

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

Bill Zwicky wrote:

> Joe Emenaker wrote:
>
>> The only way, that I can see, that would cause it to break another 
>> synthdriver is if that synthdriver *accounted* for the bug with its 
>> own code. But two wrongs don't make a right. I bug in a checksum 
>> method is a mistake. Trying to solve the problem by tweaking *other* 
>> parts of the synthdriver (instead of the checksum method) is *also* a 
>> mistake.
>
> No no, you have it backwards:  What if the synths themselves are 
> buggy?  What if someone tweaks the common driver to work around bugs 
> in their synth, but that triggers bugs in someone else's synth?

Well, you make the rule that nobody is allowed to "tweak" any of the 
common checksum methods. You can "fix" bugs that you discover, but you 
don't go in and just add some stuff that gives you the results you need 
without identifying a flaw in the existing code. In other words, if 
you're using a common checksum method and you're getting a bad checksum, 
either:
1 - There's a bug in your synthdriver
2 - You're using the wrong checksum method, or
3 - There's a bug in the checksum method itself.

In those cases, respectively, you:
1 - Fix your synthdriver
2 - Figure out the correct checksum method to use, or
3 - Notify the list that you think the checksum method is broken. Do 
*not* tweak your driver to get around the bug because, if the bug is 
ever fixed, it could break your driver.

> But if there's common code, it should be pulled out to a common place.

Of course. I thought that was a given. For example, we could use... 
org.jsynthlib.util.CommonChecksums

>> Well, I think the XML driver will. It's going to need (or want) to be 
>> able to choose checksum methods with a text string.
>
> True, but the XML driver is a completely seperate problem.

Well, I think that the XML driver shouldn't have to be a special case. I 
think the XML driver should, from the perspective of the higher JSL 
code, act just like all of the others. I've already tossed around some 
ideas with Rib Rdb off-list for cleaning the XML-specific stuff out of 
devicesConfig. But that's probably a separate discussion.

>> I'm also trying to solve future code-bloat. I'm looking forward to 
>> the day when JSL has support for 1,000+ devices. 
>
> Those are seperate problems too.  We're using Java on Gigahertz class 
> machines; bloat is not a problem.  Trust me on this, bloat is *really* 
> not a problem.

We have only about 100 synthdrivers and it takes me close to 1 minute to 
do a CVS update.

>> Even if we are lucky and *every* developer in the entire future of 
>> JSL writes flawless checksum methods, then our best possible outcome 
>> is needlessly-bloated code and a lot of duplicated effort.
>
> 1000 duplicate checksummers is *not* a problem as far as code size is 
> concerned.  But what about maintenance?  Well, how do you modify code 
> that affects multiple synths that you don't own?  How do you maintain 
> this code without having all 1000 synths around you?
>
> This is why I keep pushing for isolated code.  I think it's important 
> that hacking on a driver not affect any other driver.

Well, I don't think anybody should be "hacking" on anything in JSL. If 
something doesn't work, you don't work around it. You find the problem 
and fix it. If other people encountered the problem earlier and just 
worked around it, I'd say that they made a mistake... and that that 
should be fixed, too.

But I don't think that this will be as much of a problem as you fear. 
First, checksum routines are pretty easy to get correct, and any errors 
that are made would be fairly likely to be discovered quickly (even 
quicker when mulitple drivers use that checksum method). Secondly, I'm 
not necessarily saying that we need to go back to all of the old drivers 
and change them so that they use common checksum methods. I'm thinking 
more of future drivers.

- Joe

Re: [Jsynthlib-devel] Re: MIDI problem

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

I believe I found and fixed the bug in CAProvider causing this crash.
I also changed it to maintain the order of the devices it gets from
CoreMidi instead of scrambling them.


On Wed, 16 Mar 2005 18:27:39 -0800, Rib Rdb <ri...@gm...> wrote:
> What usually happens is that the JVM segfaults when I try to edit a
> patch. I tried playing with the output buffer and it didn't seem to
> make a difference.
> 
> 
> On Wed, 16 Mar 2005 17:35:17 -0800 (PST), Jeff Weber
> <jww...@ya...> wrote:
> > --- Rib Rdb <ri...@gm...> wrote:
> > > I tried CAProvider and the looping problem goes
> > > away, but it randomly
> > > crashes.  Bahh.  Does anyone else have this problem
> > > with PlumStone?
> >
> > Obviously, you're running on a Mac. I tried Plumstone
> > and was not able to get it working at all.
> >
> > Are the random crashes signal errors? If they are, you
> > can go into User Preferences and click on the MIDI tab
> > and adjust the MIDI Output Buffer Size and the MIDI
> > Output Delay. This does not totally get rid of the
> > signal error crashes but it cuts way down on their
> > frequency. That seems to be about the best solution
> > there is at this point (that is until Java 1.5 is
> > released for the Mac). Right now I'm running on an old
> > Blue & White G3 Mac and I have mine set with a buffer
> > size of 128 and a delay of 100ms. You may want to try
> > some different settings and see what works best for you.
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
> >
> > -------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT Products from real users.
> > Discover which products truly live up to the hype. Start reading now.
> > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> > _______________________________________________
> > Jsynthlib-devel mailing list
> > Jsy...@li...
> > https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
> >
>

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

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

Joe Emenaker wrote:

> The only way, that I can see, that would cause it to break another 
> synthdriver is if that synthdriver *accounted* for the bug with its 
> own code. But two wrongs don't make a right. I bug in a checksum 
> method is a mistake. Trying to solve the problem by tweaking *other* 
> parts of the synthdriver (instead of the checksum method) is *also* a 
> mistake.
>
No no, you have it backwards:  What if the synths themselves are buggy?  
What if someone tweaks the common driver to work around bugs in their 
synth, but that triggers bugs in someone else's synth?  Bah, there's no 
arguable point here.  The problem is one of maintaining 50+ synth 
drivers and more.  I'm inclined to think that the drivers should be kept 
seperate so that hacking on one driver doesn't break the other 49.  But 
if there's common code, it should be pulled out to a common place.

> Well, I think the XML driver will. It's going to need (or want) to be 
> able to choose checksum methods with a text string.
>
True, but the XML driver is a completely seperate problem..

> More importantly, the problem I'm trying to solve is one of long-term 
> code maintenance.

> I'm also trying to solve future code-bloat. I'm looking forward to the 
> day when JSL has support for 1,000+ devices. 

Those are seperate problems too.  We're using Java on Gigahertz class 
machines; bloat is not a problem.  Trust me on this, bloat is *really* 
not a problem.  Even with 1000 synth drivers, the overhead of Java will 
completely dwarf this little project.

Now maintainence *is* a problem, and bloat that makes maintenance 
difficult is *definitely* a problem.  Specifically:

> Even if we are lucky and *every* developer in the entire future of JSL 
> writes flawless checksum methods, then our best possible outcome is 
> needlessly-bloated code and a lot of duplicated effort.

1000 duplicate checksummers is *not* a problem as far as code size is 
concerned.  But what about maintenance?  Well, how do you modify code 
that affects multiple synths that you don't own?  How do you maintain 
this code without having all 1000 synths around you?

This is why I keep pushing for isolated code.  I think it's important 
that hacking on a driver not affect any other driver.  I also think 
common code should be placed in a common location, but in this case, we 
should only do that when someone can tell us *definitively* that two 
synths are identical.

-Bill

Re: [Jsynthlib-devel] Re: MIDI problem

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

What usually happens is that the JVM segfaults when I try to edit a
patch. I tried playing with the output buffer and it didn't seem to
make a difference.


On Wed, 16 Mar 2005 17:35:17 -0800 (PST), Jeff Weber
<jww...@ya...> wrote:
> --- Rib Rdb <ri...@gm...> wrote:
> > I tried CAProvider and the looping problem goes
> > away, but it randomly
> > crashes.  Bahh.  Does anyone else have this problem
> > with PlumStone?
> 
> Obviously, you're running on a Mac. I tried Plumstone
> and was not able to get it working at all.
> 
> Are the random crashes signal errors? If they are, you
> can go into User Preferences and click on the MIDI tab
> and adjust the MIDI Output Buffer Size and the MIDI
> Output Delay. This does not totally get rid of the
> signal error crashes but it cuts way down on their
> frequency. That seems to be about the best solution
> there is at this point (that is until Java 1.5 is
> released for the Mac). Right now I'm running on an old
> Blue & White G3 Mac and I have mine set with a buffer
> size of 128 and a delay of 100ms. You may want to try
> some different settings and see what works best for you.
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>

Re: [Jsynthlib-devel] The addWidget(...) design

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

SysexWidgets can use IParameters. I tried to make them do the same
thing you're describing.  Widgets simply call get or set on the
parameter. The parameter communicates with some sort of codec, and
also possibly tells the driver to send the updated value to the synth.

For example, the Motif driver has: (edited for clarity)
<sysex>
<decoder type="BE 7bit words" />
<!-- header, etc. -->
     <string>
       <name>Voice Name</name>
       <size>10</size>
     </string>
     <range>
       <name>QED ARP Type</name>
       <min>0</min>
       <max>127</max>
     </range>
<!-- more params -->
</sysex>
The editor then gets these parameters by name.
You could do the same type of thing in Java. Then it would look like this:
/* when the driver is created */
// create params in order so addresses are inferred
decoder.addBooleanParam("Midi Pitch Bend");

/* Then in the editor */
addWidget(leftPane,
        new CheckBoxWidget(patch, decoder.getParam("Midi Pitch Bend")),
        , 0, 10, 1, 1, -3);



On Wed, 16 Mar 2005 16:27:15 -0800, Joe Emenaker <jo...@em...> wrote:
> Brian wrote:
> 
> > My gut reaction to how to fix it would be to create a method in the
> > base class for models and senders that does nothing called setPatch
> > (Patch p). This would be called automatically by addWidget
> > on the Model and Sender sent to it.
> 
> Well, here's the "grand design" of what I'm thinking of:
> - Patch data would be given only to one of the items (widget,
> param-model, or sender) and the others would get it from that. My
> inclination would be that the param-model would house the patch data,
> since there are possible scenarios in which we might want to adjust
> parameters *outside* of the context of a graphical widget (ie,
> cross-breeding, or cut "Master Volume" by 90% in all patches in a bank).
> ParamModel would have a method for widgets to get the patch data...
> which Widget would use to obtain it, and then give it to Sender, if
> there is one.
> - I think parameter name should also be in ParamModel, for the same
> reasons (and obtained by Widget in the same way)
> - Lastly, I'd like for DataModel to be worked into this somehow. Like I
> mentioned before, the driver I'm working on now requires tat 7-bit bytes
> be decoded into 8-bit bytes, and it's easier to do this to the entire
> sysex message and than it would be for individual ParamModels to try to
> convert just the part they're interested in. Instead, by using a
> DataModel class (which holds the actual Patch object and handles all
> translation to/from Ints/Longs/Strings), the ParamModels would be given
> the DataModel object and would access the data they wanted via methods
> like getInt(offset).
> 
> The ultimate result of this would be to stop writing things like this:
> 
>     addWidget(leftPane,
>         new CheckBoxWidget("Midi Pitch Bend", patch, new
> MKSBitModel(patch, 16, 5), new MKSBitSender(patch, 16, 5, 9))
>         , 0, 10, 1, 1, -3);
> 
> and start writing them like this:
> 
>     SingleSysexDataModel datamodel = new SingleSysexDataModel(patch);
>    ....
>     addWidget(leftPane,
>         new CheckBoxWidget(new MKSBitModel("Midi Pitch Bend", datamodel,
> 16, 5), new MKSBitSender(16, 5, 9))
>         , 0, 10, 1, 1, -3);
> 
> It doesn't look *that* much cleaner, but at least the patch data is only
> passed once.
> 
> This could be cleaned up even more if ParamModels use interfaces or
> superclasses that define them as either BooleanParamModel,
> NumericParamModel, or EnumParamModel. Then, addWidget could discover
> what kind of parameter a ParamModel is and automatically give it the
> correct widget (ie, BooleanParamModel gets a CheckBoxWidget,
> NumericParamModel might get a spinner, EnumParamModel would get a
> ComboBoxWidget, etc). Then, you could use things like:
> 
>     addWidget(leftPane,
>         new MKSBitModel("Midi Pitch Bend", datamodel, 16, 5),
>         new MKSBitSender(16, 5, 9),
>         0, 10, 1, 1, -3);
> 
> Of course, you could always do things the old way if this didn't give
> you the flexibility you needed. But I think that this would clean things
> up in the general cases.
> 
> Give it some thought, if you will.
> 
> - Joe
> 
> 
>

Re: [Jsynthlib-devel] The addWidget(...) design

[Jeff W. <jww...@ya...>]

--- Joe Emenaker <jo...@em...> wrote:
> Well, here's the "grand design" of what I'm thinking
> of:
> - Patch data would be given only to one of the items
> (widget, 
> param-model, or sender) and the others would get it
> from that.

Would it be possible to use a widget with only a
ParamModel (and no Sender) or with a Sender (and no
ParamModel) with this design? In some cases you might
want to use one but not the other. I ran into this
situation with the Behringer FCB1010. The Behringer
only accepts sysex and does not recognize any
real-time messages. Is it possible there might be
other devices that only accept real-time messages and
not sysex? 


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/ 

Re: [Jsynthlib-devel] Re: MIDI problem

[Jeff W. <jww...@ya...>]

--- Rib Rdb <ri...@gm...> wrote:
> I tried CAProvider and the looping problem goes
> away, but it randomly
> crashes.  Bahh.  Does anyone else have this problem
> with PlumStone?

Obviously, you're running on a Mac. I tried Plumstone
and was not able to get it working at all.

Are the random crashes signal errors? If they are, you
can go into User Preferences and click on the MIDI tab
and adjust the MIDI Output Buffer Size and the MIDI
Output Delay. This does not totally get rid of the
signal error crashes but it cuts way down on their
frequency. That seems to be about the best solution
there is at this point (that is until Java 1.5 is
released for the Mac). Right now I'm running on an old
Blue & White G3 Mac and I have mine set with a buffer
size of 128 and a delay of 100ms. You may want to try
some different settings and see what works best for you.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [Jsynthlib-devel] Sysex Spec for V-Amp 2 Available

[Jeff W. <jww...@ya...>]

--- Joe Emenaker <jo...@em...> wrote:
> By the way, do you have the specs for any other of
> the v-amp products?

As far as I am aware the original V-Amp spec and the
new V-Amp 2 spec are the only ones in existence. (This
spec covers the V-Amp 2, V-Amp Pro, and the V-Ampire.)
I don't believe there is a separate one for the Bass
V-Amp but you could check with Behringer (just go to
http://behringer-en.custhelp.com/. Create an account
if you don't already have one, and then click on the
"Ask a Question" link. They should get back to you
within about five business days).

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [Jsynthlib-devel] The addWidget(...) design

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

Brian wrote:

> My gut reaction to how to fix it would be to create a method in the
> base class for models and senders that does nothing called setPatch 
> (Patch p). This would be called automatically by addWidget
> on the Model and Sender sent to it.

Well, here's the "grand design" of what I'm thinking of:
- Patch data would be given only to one of the items (widget, 
param-model, or sender) and the others would get it from that. My 
inclination would be that the param-model would house the patch data, 
since there are possible scenarios in which we might want to adjust 
parameters *outside* of the context of a graphical widget (ie, 
cross-breeding, or cut "Master Volume" by 90% in all patches in a bank). 
ParamModel would have a method for widgets to get the patch data... 
which Widget would use to obtain it, and then give it to Sender, if 
there is one.
- I think parameter name should also be in ParamModel, for the same 
reasons (and obtained by Widget in the same way)
- Lastly, I'd like for DataModel to be worked into this somehow. Like I 
mentioned before, the driver I'm working on now requires tat 7-bit bytes 
be decoded into 8-bit bytes, and it's easier to do this to the entire 
sysex message and than it would be for individual ParamModels to try to 
convert just the part they're interested in. Instead, by using a 
DataModel class (which holds the actual Patch object and handles all 
translation to/from Ints/Longs/Strings), the ParamModels would be given 
the DataModel object and would access the data they wanted via methods 
like getInt(offset).

The ultimate result of this would be to stop writing things like this:

    addWidget(leftPane,
        new CheckBoxWidget("Midi Pitch Bend", patch, new 
MKSBitModel(patch, 16, 5), new MKSBitSender(patch, 16, 5, 9))
        , 0, 10, 1, 1, -3);

and start writing them like this:

    SingleSysexDataModel datamodel = new SingleSysexDataModel(patch);
   ....
    addWidget(leftPane,
        new CheckBoxWidget(new MKSBitModel("Midi Pitch Bend", datamodel, 
16, 5), new MKSBitSender(16, 5, 9))
        , 0, 10, 1, 1, -3);

It doesn't look *that* much cleaner, but at least the patch data is only 
passed once.

This could be cleaned up even more if ParamModels use interfaces or 
superclasses that define them as either BooleanParamModel, 
NumericParamModel, or EnumParamModel. Then, addWidget could discover 
what kind of parameter a ParamModel is and automatically give it the 
correct widget (ie, BooleanParamModel gets a CheckBoxWidget, 
NumericParamModel might get a spinner, EnumParamModel would get a 
ComboBoxWidget, etc). Then, you could use things like:

    addWidget(leftPane,
        new MKSBitModel("Midi Pitch Bend", datamodel, 16, 5),
        new MKSBitSender(16, 5, 9),
        0, 10, 1, 1, -3);

Of course, you could always do things the old way if this didn't give 
you the flexibility you needed. But I think that this would clean things 
up in the general cases.

Give it some thought, if you will.

- Joe