Menu
▾
▴
jsynthlib-devel — Mailing list for developers and users interested in improving the JSynthLib.
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(90) |
Sep
(38) |
Oct
(22) |
Nov
(3) |
Dec
(13) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(40) |
Feb
(119) |
Mar
(236) |
Apr
(41) |
May
(45) |
Jun
(10) |
Jul
(9) |
Aug
(12) |
Sep
(5) |
Oct
(17) |
Nov
(2) |
Dec
(3) |
| 2006 |
Jan
(23) |
Feb
(36) |
Mar
(49) |
Apr
|
May
|
Jun
(1) |
Jul
(11) |
Aug
(11) |
Sep
(15) |
Oct
(30) |
Nov
(36) |
Dec
(13) |
| 2007 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
(3) |
Jun
(7) |
Jul
(4) |
Aug
(1) |
Sep
(19) |
Oct
(1) |
Nov
(2) |
Dec
(5) |
| 2008 |
Jan
|
Feb
(2) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
(5) |
Dec
|
| 2009 |
Jan
(26) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(26) |
Sep
(6) |
Oct
(5) |
Nov
(6) |
Dec
(6) |
| 2010 |
Jan
(3) |
Feb
|
Mar
(5) |
Apr
|
May
(1) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
(6) |
Aug
(8) |
Sep
(220) |
Oct
(9) |
Nov
(27) |
Dec
(33) |
| 2012 |
Jan
|
Feb
(4) |
Mar
(9) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
|
| 2013 |
Jan
(6) |
Feb
(20) |
Mar
(6) |
Apr
(3) |
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(17) |
Nov
(2) |
Dec
|
| 2014 |
Jan
(9) |
Feb
(1) |
Mar
(11) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
(2) |
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Hiroo H. <hir...@co...> - 2005-03-13 20:34:27
|
Joachim,
Joachim> Five minutes ago I thought this idea is very good.
Joachim> Now I'm not shure anymore. ;)
If a driver uses 'BANK_CHANGE_METHOD_LSB', for example, it is more clear
and easy to be read just writing
msg.setMessage(ShortMessage.CONTROL_CHANGE, getChannel() - 1,
0x20, // Bank Select (LSB)
bankNum); // Bank Number (MSB)
send(msg);
then using your method, isn't it?
This is similar to the check-sum handling. Encapsulating a simple thing
may make it just complicated.
--
Hiroo Hayashi
|
|
From: Hiroo H. <hir...@co...> - 2005-03-13 20:24:43
|
Federico, federico> 1) the MKS7 driver i just developed, controls only one timbral part. federico> to get control of all three parts (chord,melody,bass), i have to create federico> 3 driver instances, with 3 different IDs and MIDICHANs. I don't understand why you have to create 3 driver instances. Why one driver cannot handle those three parts? -- Hiroo Hayashi |
|
From: Hiroo H. <hir...@co...> - 2005-03-13 19:41:26
|
Joe, Joachim> By the way: It would be helpful if you don't ask questions Joachim> first and then explain your real intention a few mails Joachim> afterwards. It would speed up the process if you come Joachim> in with your intention first. ;) I agree with Joachim. Joe, please don't forget that the first language of many members in this ML is not English. I'm guessing you are typing as you are talking in a conversation. It takes more time for me to read your mail than for you to write the mail probably. As many how-to says the communication on mail is different from on on a conversation, and it requires some cares. Many of (not all of:-)) your suggestion is really valuable. But it's hard for me to read your messages. It would help this project if you spend your time a little more before you send out your mail. Regards, P.S. Joe, I'm subscribing this mailing list. Don't put my address when you reply to me. -- Hiroo Hayashi |
|
From: Hiroo H. <hir...@co...> - 2005-03-13 19:41:21
|
Brian> My idea is this. *Most* synths have a single F0 .. F7 pair in their Brian> sysex, and many have a constant known size. Maybe drivers could have a Brian> function like isFullPatch(Arry of Bytes), that the receive would call Brian> every so often. Brian> The base Driver class would be set to just check for an F7. This way 95% Brian> of the drivers would remain the same. The remaining drivers would have Brian> to override this method. > "*Most* synths have a single F0 .. F7 pair in their sysex." Is this true? I thought only old synth (or for compatibility with old synth) uses a single sysex MIDI message even for a large data transfer. I think more synths know the size of data which they returns when sysex is requested. So it is better to use data size number first. If data size is unknown, we can check for an F7. If number of sysex message is known, we can check for the number of F7. -- Hiroo Hayashi |
|
From: Hiroo H. <hir...@co...> - 2005-03-13 19:41:09
|
Hi,
I've run over this discussion. I could not read one word by one word,
so I may misunderstand something.
In this mail I'd like to propose two things.
1. Let's complete JSynthLib 1.0.
2. Then start for JSynthLib 2.0 with big changes (User I/F, file
format, etc.)
First I thank you Brain for his starting this great project. It's much
more easy to improve existing code or to comment (or criticize) it than
to create it from scratch. It learned a lot from your program. There
are many good ideas (ParamModel is one of them).
I have no experience of commercial librarians. But I guess they cannot
support all of MIDI devices. They probably have a feature to support
any MIDI device for some degree by letting user set up something, but
there are limit without full programming language. By having this GPLed
librarian, anyone who can do programming can have librarian for any MIDI
device.
Of course, as anyone including Brian agree, there are lots of things to
be improved. (I've been doing my best to improve JSL as far as I can.)
As we discussed before, once we will done for the package structure
change, JSL can be version 1.0.
Although Rib and Joe taught me how to change package by Eclipse, it's
not still clear for me. And they wrote it would be easy, but I'm still
afraid once I start it, it will take lots of time. I'll move my home
over Pacific Ocean soon. (I'll go back to Japan with my family.) I will
not be able to spend my time for this project as I did for a couple of
months at least. So, don't rely on me for the package restructuring work.
Joe, could you drive this issue? You were pushing this issue very hard,
weren't you?
I agree with Joe on the point there are room to improve the user
interface. The current UI allow user to put any kind of patch in a
library. This gives us some freedom. But I don't think it is worth to
let users select driver (MIDI device) every time they do something.
(For example, new patch dialog does not have to have Device combo box if
a frame is dedicated for a MIDI device.) And I think we also need to
change the file format. By having function to import or convert the
current format file, we can change it and go forward. The combination
of an XML file and binary Sysex files is my proposal.
Again we have to release 1.0 before the big changes.
Regards,
--
Hiroo Hayashi
|
|
From: Hiroo H. <hir...@co...> - 2005-03-13 19:27:13
|
Bill> * The CZ sysex has more bits than the front panel -- i.e. there are Bill> waveforms and parameter values accessible in the sysex that aren't Bill> available from the physical synth. The editor's normal mode mimics the Bill> panel, but "hack mode" opens up the extras. The switch is in source Bill> right now; is there a good place to put it in the GUI? Note that the Bill> editor window has to be rebuilt when this is toggled. You can use Pereference. For example my Roland TD-6 drum editor shows only pads which a user enabled on the preference window. I described this in programming.html briefly. --------------------- III.e.3. Keeping Persistent Parameters The second constructor has an argument, java.util.prefs.Preferences object prefs. By using this and overriding config() method, your driver can have persistent parameters for your synth driver. See actual code, for example RolandTD6Device, for more details. ---------------------- Bill> * The CZ doesn't appear to support updating individual params, so I Bill> didn't add any senders. This means user must twiddle sliders, then Bill> double-click the patch in the library to try it out. Is there a better Bill> way to handle this? I don't want to queue up kilobytes of sysex messages. You can add a "Send" (or "Sync"?) button on your editor. It is a little bit better than changing frame and doing double click. -- Hiroo Hayashi |
|
From: Bill Z. <wrz...@po...> - 2005-03-13 17:26:25
|
Joe Emenaker wrote: > Can you do a tabbed panel, and put the "front panel" controls on one > called, maybe, "Front Panel" and the other stuff in another panel > (like "Extras"), or would it be really awkward to break the parameters > up like that? They don't divide that way. The controls are all the same, but hack mode opens up wider value ranges. But that's actually a good idea .. it would let the user see how synth values translate to sysex values. So that brings up another question: If I have two sliders editing the same parameter, how do I get one to reflect changes in the other? -Bill |
|
From: Hiroo H. <hir...@co...> - 2005-03-13 14:58:43
|
Joachim> > Does the mailing list handle attachments??? Joachim> Joachim> Yes, e.g. federico has attached his MKS-7 code 2 days ago. Is it only me who does not prefer attachments, because it consumes my mail box? You can consider to use the tracker on sourceForge site to share your file. -- Hiroo Hayashi |
|
From: Joe E. <jo...@em...> - 2005-03-13 11:51:51
|
Bill Zwicky wrote: > * The CZ doesn't appear to support updating individual params, so I > didn't add any senders. This means user must twiddle sliders, then > double-click the patch in the library to try it out. Is there a > better way to handle this? I don't want to queue up kilobytes of > sysex messages. Can you do a tabbed panel, and put the "front panel" controls on one called, maybe, "Front Panel" and the other stuff in another panel (like "Extras"), or would it be really awkward to break the parameters up like that? - Joe |
|
From: Bill Z. <wrz...@po...> - 2005-03-13 07:45:24
|
CZ-1000 editor is finally done. But I have questions: * The CZ sysex has more bits than the front panel -- i.e. there are waveforms and parameter values accessible in the sysex that aren't available from the physical synth. The editor's normal mode mimics the panel, but "hack mode" opens up the extras. The switch is in source right now; is there a good place to put it in the GUI? Note that the editor window has to be rebuilt when this is toggled. * The CZ doesn't appear to support updating individual params, so I didn't add any senders. This means user must twiddle sliders, then double-click the patch in the library to try it out. Is there a better way to handle this? I don't want to queue up kilobytes of sysex messages. -Bill |
|
From: Joe E. <jo...@em...> - 2005-03-13 05:07:34
|
Hiroo Hayashi wrote:
>Why Constants.java is a class not an interface?
>
>If it is an interface, we don't have to prefix with 'Constants.' for
>every reference. If there is not a good reason, I propose to change it
>to interface.
>
>
Actually, I've been surprised at how little Constants is used. I'm sure
that there are many more constant values being used in JSL that *could*
be in Constants, but the class just hasn't been fully embraced. Right
now... aren't there less than 10 values in there now? Since it doesn't
seem to be being used at *the* central location for all constants, I'd
be more in favor of splitting it up into module-level constants... like
a set of constants for the the part that interacts with the
synthdrivers, and one for the part that saves settings, etc.
But that's not really on-topic with your question.
I'm not really in favor of turning it into an interface because it would
make the code more cryptic. Keep in mind that the programming.html
advises new developers to "Spend some time looking through the driver
code for other synthesizers and you'll basically pick it up by osmosis".
If the source code is expected to substitute for an explanation of how
to work with the API, then you need to keep the code in a format that
can be read and easily figured out.
When I see a class implementing interfaces, I use that as a cue as to
how it is being used by the rest of the program. For example, if I see:
class MyClass implements PatchEditor, NewPatchCreator, PatchMover,
PatchBlender {
then I would think that this class is being used to edit and move
patches, blend patches with something, and create new patches. On the
other hand, if I see
class MyClass implements Constants {
then I'm going to think that, somewhere, it must be defining methods
that help it act like... uhhh... a "constant"... which would just
confuse me.
So, until there's a well-written "How to write a synthdriver" howto,
then I'd vote against making Constants into an interface.
- Joe
|
|
From: Hiroo H. <hir...@co...> - 2005-03-13 00:27:02
|
Hi,
I guess Federico's question was how can he get developer account.
I think we should make the policy clear and document it in
programming.html.
Here is my proposal to start discussion.
If a developer wants to get developer account to maintain his
driver, he can get it by asking it on this mailing list.
I think this is OK.
Anyone can make changes on core. It is required (recommended?)
to ask ML before making change.
I'm not sure for this.
Once the development of your driver is done, and you don't need
your developer account, send a mail to ML. (Of course you can get
developer account any time again.)
I do not see the following developer's names in my mail archive.
Bernadette Emsenhuber
Chris Halls
Juha Tukkinen
I remove their name from the list of developers? (Again anyone can be
on this list any time.)
Give me your better proposal. Actual example is welcome. I can do
cut&paste.
Thanks.
Joachim> > btw: how to get a cvs account?
Joachim> > why don't add a CVS section in the documentation, to explain
Joachim> > how to get
Joachim> > an account and check in a driver?
Joachim> Because SourceForge already explains that:
Joachim> http://sourceforge.net/cvs/?group_id=41208
Joachim> Check in works only if you are a project developer.
--
Hiroo Hayashi
|
|
From: Hiroo H. <hir...@co...> - 2005-03-12 23:57:12
|
I've been having one question. Why Constants.java is a class not an interface? If it is an interface, we don't have to prefix with 'Constants.' for every reference. If there is not a good reason, I propose to change it to interface. Thanks. -- Hiroo Hayashi |
|
From: Hiroo H. <hir...@co...> - 2005-03-12 23:34:47
|
Hi,
Well, there were so many mails on this ML this week. It's good news for
this project. But it's very difficult for me to read them...
Let me reply on this check sum issue first. (Sorry, this mail gets long,
too.)
There were discussions about this issue since I joined this ML. The
current implementation is the best way I could think of.
1. The interfaces between core and synthdrivers expect a patch whose check
sum is already calculated, and do not have method to calculate check sum.
2. core interfaces a patch by using IPatch interface.
3. The current synthdrivers extend Driver class which is called via
IPatch interface.
4. Driver class has the following *protected* classes.
/**
* Calculate check sum of a <code>Patch</code>.<p>
*
* Need to be overridden if a patch is consist from multiple SysEX
* messages.
*
* @param p a <code>Patch</code> value
*/
protected void calculateChecksum(Patch p) {
calculateChecksum(p, checksumStart, checksumEnd, checksumOffset);
}
The original Driver class had the method above.
/**
* Calculate check sum of a <code>Patch</code>.
* <p>
*
* This method is called by calculateChecksum(Patch). The checksum
* calculation method of this method is used by Roland, YAMAHA, etc.
* Override this for different checksum calculation method.
=2E..
*/
protected void calculateChecksum(Patch patch, int start, int end,
int offset) {
DriverUtil.calculateChecksum(patch.sysex, start, end, offset);
}
The method above was introduced to make being reused easier.
DriverUtils class has the following *static* method.
By using *static* method we can call it without inheriting nor creating
object. (For example a bank driver can share check sum method with a
single driver easily).
/**
* Calculate check sum of a byte array <code>sysex</code>.
* <p>
*
* The checksum calculation method of this method is used by Roland, YA=
MAHA,
* etc.<p>
*
=2E..
* @see Driver#calculateChecksum(Patch)
*/
public static void calculateChecksum(byte[] sysex, int start, int end, =
int ofs) {
int sum =3D 0;
for (int i =3D start; i <=3D end; i++)
sum +=3D sysex[i];
sysex[ofs] =3D (byte) (-sum & 0x7f);
}
What we can do is to add variation of this method on this class and let
programmers choose one of them. The most difficult work is to name them
as someone pointed.
It is not difficult for programmers to implement this level of code. And
it may be more difficult for them to select one of methods provided:-)=20
And my manual for Roland synth explain check sum as follows;
aa + bb + cc + ... + hh =3D sum
sum / 128 =3D quotient ... remainder
128 - remainder =3D check sum
It might be even more difficult to understand the method above
implements this calculation method. Better documentation may help some,
but I have little hope.
--=20
Hiroo Hayashi
|
|
From: Joe E. <jo...@em...> - 2005-03-12 09:07:08
|
For the driver for the drum machine, I'm planning on editing patterns with a grid, with all of the drum instruments arranged vertically and the time-slices (like 1/16 notes, or whatever) going across. It's a long shot... but it doesn't hurt to ask before I actually write one: Do we have a widget that does something like this? If not... is there anything anyone would *want* in a widget like this? - Joe |
|
From: Joe E. <jo...@em...> - 2005-03-11 20:32:30
|
Bill Zwicky wrote:
> I got a better idea: Since we're using an object-oriented language,
> why not use objects?
>
> synthdrivers.Generic.Checksum
> synthdrivers.Boss.DRChecksum
> synthdrivers.Casio.CZ1000.Driver implements Checksum
>
> This way if a new checksum is developed, noone needs to go edit the
> existing code base, nor twiddle the double-indirection constants, nor
> edit documentation in multiple places (source, Wiki).
Well.... a few reasons why that could be bad are:
1 - There's probably a lot of redundancy/commonality in checksum
algorithms, and that redundancy doesn't follow any lines of inheirtance
of the classes. In other words, it would probably be pretty rare that a
synthdriver would get the apropriate checksum method from its superclass
(if at all). Without benefitting from inheritance, each synthdriver
still has to define their checksum method, which means that you'd get a
lot of stuff like this:
public Checksum generateChecksum(Patch p) {
return synthdrivers.Casio.CZ1000.Driver.generateChecksum(p);
}
2 - Not only is the above code unsightly, it also causes synthdrivers to
stick their fingers into other synthdrivers' business. This is bad for
two reasons. First, (and this might just be personal preference) I've
found that it's poor design to have low-level parts of the software try
to have any sort of awareness of other parts. A synthdriver should have
absolutely no clue (and, ideally, no way of finding out) if it's the
only driver loaded, or one of 100. Usually, this ideal is merely good
for helping to promote good OO design, which isn't a life-or-death
situation. However, the *second* reason makes it a little more crucial.
The second reason is that I'm still holding out hopes that, someday, JSL
will allow the user to dynamically browse/retrieve/update their drivers
over the net. If this ever becomes reality, then we can't be certain
*which* synthdrivers are currently installed on the user's machine and
which aren't. Unless we want to come up with some kooky requirement
system (ie, "Korg ER-1" requries "CasioCZ1000"), then this could be a
deal-killer for any future net-based driver download system.
3 - This solution would make it harder on the XML driver. I'd personally
like to see
<Checksum type="YAMAHA_PRE_1996" />
instead of
<Checksum class="synthdrivers.Yamaha.EX5.BankDriver" />
- Joe
|
|
From: Joe E. <jo...@em...> - 2005-03-11 19:46:54
|
Bill Zwicky wrote: > Joe Emenaker wrote: > >> I made a "DataModel" interface. The idea behind it is that it handles >> all of the nuisance of stripping off leading bytes (ie, F0, manufID, >> devID, etc) and trailing F0 and it handles any conversion to/from >> 8-bit bytes or whatnot. >> >> Then, I made a new ParamModel which, when it needs data, asks the >> DataModel for it. So, the ParamModel and addWidget never need to see >> the actual Patch. > > > So did I, good job. :) I think DataModel might be the next stage in the evolution. ParamModels alone won't really cut it (in my case anyway) because I'm having to do a 7-bit-to-8-bit conversion on the whole patch before I do anything with it. If I did this in each ParamModel, there'd be a conversion happening for *every* Widget in my editor which, potentially, could lead to long delays for the editor to load. Also, because the 7-to-8 encoding "intermingles" the bits of each byte with neighboring ones, it'd be very tricky to try to have each ParamModel try to sneak its param data into the undecoded patch data itself. > Two things to watch out for: > * In Java, bytes are signed. So if the range is 0..255 before, > casting it to a (Byte) will change that to -128..127. Thus, reading > patch.sysex[index] may yield negative numbers. I had to compensate in > my CZModel.getByte. Yeah... I've hit this kinda thing before. Most-recently, it was when doing right-shifting of bits. If you do ( 0x80 >> 1 ), you don't get 0x40, you get 0xC0 because Java figures that the high-bit was on, and needs to stay that way. Uh... okay. > * Java ints are only 4 bytes, so you can't grab any more than that at > once. Ints are also signed, so if you grab 4 bytes, you'll get > negative numbers again. Longs are 8 bytes. Right! Well, here's where things can get really fun with DataModels. Some synths (like the Alesis I'm working on) use 8-bit bytes for the actual patch data, some use 7-bit. The DataModel would be aware of this. Part of the interaction between ParamModel and DataModel could be one where ParamModel declares to DataModel how many bytes it wants, and what the highest value it expects to be able to use with it. Then, the DataModel would do the calculations to make sure that it was possible. For example, suppose DataModel has a method called isInRange(int bytes, long highest value)... For a DataModel which used 7-bit bytes, isInRange(1,127) returns true isInRange(1,128) returns false isInRange(2 16383) returns true isInRange(2,16384) returns false Meanwhile, for a DataModel which uses 8-bit bytes, isInRange(1,128) would return true.... Maybe this is overkill... but I like the encapsulation of it.... and I'm an encapsulation whore. - Joe |
|
From: Bill Z. <wrz...@po...> - 2005-03-11 03:04:40
|
Joe Emenaker wrote: > I made a "DataModel" interface. The idea behind it is that it handles > all of the nuisance of stripping off leading bytes (ie, F0, manufID, > devID, etc) and trailing F0 and it handles any conversion to/from > 8-bit bytes or whatnot. > > Then, I made a new ParamModel which, when it needs data, asks the > DataModel for it. So, the ParamModel and addWidget never need to see > the actual Patch. So did I, good job. :) Two things to watch out for: * In Java, bytes are signed. So if the range is 0..255 before, casting it to a (Byte) will change that to -128..127. Thus, reading patch.sysex[index] may yield negative numbers. I had to compensate in my CZModel.getByte. * Java ints are only 4 bytes, so you can't grab any more than that at once. Ints are also signed, so if you grab 4 bytes, you'll get negative numbers again. Longs are 8 bytes. -Bill |
|
From: Joe E. <jo...@em...> - 2005-03-11 02:53:19
|
Bill Zwicky wrote: > Joe Emenaker wrote: > >> From a brief look at the ParamModel class, it looks like it's not >> really going to help me here. As a result, I suspect that the *Widget >> system is, likewise, not available to me, correct? > > In-correct, Widgets will work just fine for you, but you need to make > your own model classes. This is really easy, there's even > instructions on jsl.org. I had to crank out a whole buncha custom > model classes for my CZ; it's annoying, but easy. Well, I just tried a different approach... and I'm interested in its potential. I made a "DataModel" interface. The idea behind it is that it handles all of the nuisance of stripping off leading bytes (ie, F0, manufID, devID, etc) and trailing F0 and it handles any conversion to/from 8-bit bytes or whatnot. Then, I made a new ParamModel which, when it needs data, asks the DataModel for it. So, the ParamModel and addWidget never need to see the actual Patch. The beauty here (well, *I* think it's pretty neat, anyway) is that the DataModel would be able to handle multi-byte values. It would know whether to use LSB-first or MSB-first. It would also know how strings are stored (ASCII... 0-terminated... whatever). So the ParamModel would be able to just ask for multi-byte values by asking for the offset and the number of bytes: dataModel.getInt(0x245,4); // Get a 4-byte int or.... dataModel.setInt(0x245,4,somevalue); - Joe |
|
From: Bill Z. <wrz...@po...> - 2005-03-11 02:40:13
|
Joe Emenaker wrote: > /** > * 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. > */ I got a better idea: Since we're using an object-oriented language, why not use objects? synthdrivers.Generic.Checksum synthdrivers.Boss.DRChecksum synthdrivers.Casio.CZ1000.Driver implements Checksum This way if a new checksum is developed, noone needs to go edit the existing code base, nor twiddle the double-indirection constants, nor edit documentation in multiple places (source, Wiki). -Bill |
|
From: Jeff W. <jww...@ya...> - 2005-03-11 02:35:28
|
Joe>The current driver I"m working on deals with 8-bit bytes (after Joe>unpacking them from the 7-bit ones that MIDI uses). It *also* uses Joe>some values that span mulitple bytes (ie, MSB/LSB). Joe> Joe>From a brief look at the ParamModel class, it looks like it"s not Joe>really going to help me here. As a result, I suspect that the Joe>*Widget system is, likewise, not available to me, correct? I don't think there's any reason you can't use a standard ParamModel to edit an 8-bit byte. And I don't think there's any reason you can't create a subclass of a ParamModel that can edit two (or more) contiguous (or even non-contiguous) bytes. And all can be done under control of the Widget of your choice. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: Bill Z. <wrz...@po...> - 2005-03-11 02:29:38
|
Joe Emenaker wrote: > From a brief look at the ParamModel class, it looks like it's not > really going to help me here. As a result, I suspect that the *Widget > system is, likewise, not available to me, correct? > In-correct, Widgets will work just fine for you, but you need to make your own model classes. This is really easy, there's even instructions on jsl.org. I had to crank out a whole buncha custom model classes for my CZ; it's annoying, but easy. -Bill |
|
From: Joe E. <jo...@em...> - 2005-03-11 00:24:30
|
The current driver I'm working on deals with 8-bit bytes (after unpacking them from the 7-bit ones that MIDI uses). It *also* uses some values that span mulitple bytes (ie, MSB/LSB). From a brief look at the ParamModel class, it looks like it's not really going to help me here. As a result, I suspect that the *Widget system is, likewise, not available to me, correct? - Joe |
|
From: Joe E. <jo...@em...> - 2005-03-10 22:21:13
|
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 |
|
From: Joe E. <jo...@em...> - 2005-03-10 21:48:09
|
Brian wrote: > Originally, JSynthLib didn't track MidiIn ports for each device. Only > the recieve window even dealt with MidiIn. So when you did a patch > receive you would give the port you wanted to receive on, and then > would always have to do the dump manually from the synth. You would > see bytes received and when you knew the dump was done, hit OK. At > that point JSynthLib would look for a matching driver. > > This was improved upon greatly several versions back by having > JSynthLib track a MidiIn for each synth and to request patch dumps by > selecting a Driver rather than a port. Now we know in advance what > type of patch we are getting. So the question then, can we figure a > way to let the driver say, "This is enough, this patch is complete" So > we don't have to count on the user to tell us? My kneejerk idea to solve this would be to let the driver return a boolean (false="I need more messages to complete this", true="The current set of sysexes you gave me are a complete patch") when JSL offers it a patch/message. The problem, however, is that the method used to "offer" the message to a driver is "acceptsPatch", isn't it? And that *already* returns a boolean. So, unless you want it to return a tri-state (0=no, 1=need more messages, 2=yes).... then you might need to add a second method, like "acceptsPatchWithMore". So, if a driver is offered a message (or set of messages) which look like a good start, but aren't complete, would return *false* to acceptsPatch, and *true* to acceptsPatchWithMore. Then, JSL would just cycle through the drivers calling acceptsPatch and, if it got no takers, would try them all again with acceptsPatchWithMore. Then, you just have Driver default to return false for acceptsPatchWithMore and those with a need would override it. However, you then have a potentially sticky issue with the possibility of other sysex messages getting mixed in with your patch dump. For example, let's say that you start a multi-message dump from a synth and then, somehow, you start a dump from *another* synth. They could get intermingled and then you'd have a situation where a string of messages are being collected for a synth and then... suddenly, the deal is off.... the driver is now returning false from acceptsPatchWithMore. > Anyone willing to take a look into this. We also need to make sure to > divorce the receive dialog from the actual recieve logic. We need to > be able to call a Get function from anywhere, not just the dialog. > Something lke Normally, I would. I like refactoring and cleaning existing code. I think I like it even more than writing *new* code, but I'm currently busy teaching myself how to write a driver right now. :) I do have one question though. If I tell JSL to get a patch from a synth and a patch from something *else* comes in, does JSL still cycle through all of the current drivers (or all of the ones on that channel) calling acceptsPatch, or does it only check it for the driver it's expecting one for? Also, what's the spec'd behavior in this case? - Joe |
89 messages has been excluded from this view by a project administrator.
