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

Re: [Jsynthlib-devel] Menu and toolbar question...

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

Rib Rdb wrote:
> On 2/28/06, Joe Emenaker <jo...@em...> wrote:
>   
>> So, should LibraryFrame and SceneFrame have their own menus in SDI mode
>> at all then? Or should they just have them when not on a Mac?
>>     
> They need to have them on the Mac. The JVM will display the one for
> the active frame at the top of the screen.
Oh....   weird.

- Joe

Re: [Jsynthlib-devel] Menu and toolbar question...

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

Rib Rdb wrote:
> Yes per window menus are discouraged. Instead, the system menu shows
> the menubar for the focused frame. That's why they all share the same
> items, otherwise items will disappear and reappear in the system menu
> as you switch between windows.
>   
So, should LibraryFrame and SceneFrame have their own menus in SDI mode 
at all then? Or should they just have them when not on a Mac?

- Joe

Re: [Jsynthlib-devel] Menu and toolbar question...

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

On 2/28/06, Joe Emenaker <jo...@em...> wrote:
> Rib Rdb wrote:
> > On 2/28/06, Joe Emenaker <jo...@em...> wrote:
> >
> >> 2 - Same thing goes for menus. All frames seem to get a common menu...
> >> even the main app window (which would be the DesktopPane in MDI mode).
> >> This seems a little redundant. Would we want each library to get its o=
wn
> >> menu? Are there certain menu items which belong only in the context of=
 a
> >> library/scene frame or in the context of the main app frame? For
> >> example, perhaps cut/copy/paste shouldn't be in the main app frame (on=
ly
> >> in library and scene frames) while the "Preferences..." item would be
> >> only available in the main app frame?
> >>
> > I'm not sure I follow here.  In MDI mode, only the DesktopPane has a
> > menu since it is the only window. As far as I remember, there is no
> > main app frame in SDI mode.
> Well, there's a "toolbar" frame that, initially, is the only frame you
> get when you start JSL in SDI mode. I'm calling that the "main app"
> frame. I'd call it the toolbar frame, but individual libraries and
> scenes can have their own toolbars.
> > Instead, each window is supposed to be
> > independent.  Why should I have to switch to some other window in
> > order to open the preferences?
> >
> Well, I think it's a context thing. If a user sees a "Preferences..."
> menu in a LibraryFrame, they might believe that it accesses the
> preferences for *that* LibraryFrame *only*.
>
> I'm not very familiar with what the common behavior is for Mac or SDI
> apps, but I know that Logic Audio behaves a little like this (look at
> http://www.audiomidi.com/classroom/thomsontips/images/tt3_logic_keycom_me=
nu.gif
> and you can see a little menu within the frame... hidden behind the top
> menu). There's the main app menu on the top of the screen and then each
> window has a completely different menu which has options just for that
> menu. Personally, I find *that* to be a little strange... but I find
> Macs, in general, to be strange. For a normal Mac user, this might seem
> the most-intuitive way.

That does indeed seem strange. I've never seen something with both a
menu at the top of the screen and menus on the windows.

> > SDI was designed for Mac OS X, where MDI does not exist.  Apple's UI
> > standards require that menu items be disabled instead of removed for
> > windows where they don't apply.
> >
> But that's just for the case of the system menu (or whatever you call
> that thing at the top of the screen), right? For a menu that's *in* that
> particular frame, does that still apply? Or does the Mac spec discourage
> per-window menus altogether?

Yes per window menus are discouraged.  Instead, the system menu shows
the menubar for the focused frame. That's why they all share the same
items, otherwise items will disappear and reappear in the system menu
as you switch between windows.

Re: [Jsynthlib-devel] Menu and toolbar question...

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

Rib Rdb wrote:
> On 2/28/06, Joe Emenaker <jo...@em...> wrote:
>   
>> 2 - Same thing goes for menus. All frames seem to get a common menu...
>> even the main app window (which would be the DesktopPane in MDI mode).
>> This seems a little redundant. Would we want each library to get its own
>> menu? Are there certain menu items which belong only in the context of a
>> library/scene frame or in the context of the main app frame? For
>> example, perhaps cut/copy/paste shouldn't be in the main app frame (only
>> in library and scene frames) while the "Preferences..." item would be
>> only available in the main app frame?
>>     
> I'm not sure I follow here.  In MDI mode, only the DesktopPane has a
> menu since it is the only window. As far as I remember, there is no
> main app frame in SDI mode.
Well, there's a "toolbar" frame that, initially, is the only frame you 
get when you start JSL in SDI mode. I'm calling that the "main app" 
frame. I'd call it the toolbar frame, but individual libraries and 
scenes can have their own toolbars.
> Instead, each window is supposed to be
> independent.  Why should I have to switch to some other window in
> order to open the preferences?
>   
Well, I think it's a context thing. If a user sees a "Preferences..." 
menu in a LibraryFrame, they might believe that it accesses the 
preferences for *that* LibraryFrame *only*.

I'm not very familiar with what the common behavior is for Mac or SDI 
apps, but I know that Logic Audio behaves a little like this (look at 
http://www.audiomidi.com/classroom/thomsontips/images/tt3_logic_keycom_menu.gif 
and you can see a little menu within the frame... hidden behind the top 
menu). There's the main app menu on the top of the screen and then each 
window has a completely different menu which has options just for that 
menu. Personally, I find *that* to be a little strange... but I find 
Macs, in general, to be strange. For a normal Mac user, this might seem 
the most-intuitive way.
> SDI was designed for Mac OS X, where MDI does not exist.  Apple's UI
> standards require that menu items be disabled instead of removed for
> windows where they don't apply.
>   
But that's just for the case of the system menu (or whatever you call 
that thing at the top of the screen), right? For a menu that's *in* that 
particular frame, does that still apply? Or does the Mac spec discourage 
per-window menus altogether?

- Joe

Re: [Jsynthlib-devel] Menu and toolbar question...

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

On 2/28/06, Joe Emenaker <jo...@em...> wrote:
> In SDI mode, each library/scene frame gets its own menu and can also
> have its own toolbar. I've noticed a few things about this that raise
> some UI questions:
>
> 1 - All of the toolbars seem to be the same instance. If I have multiple
> libraries open with no patches selected in any of them, then the "cut"
> and "copy" toolbuttons are greyed. If I select a patch in one of the
> frames, the "cut" and "copy" toolbuttons are enabled on *all* of the
> windows. Do we want this to happen, or should each frame have its own
> toolbar that reflects the state of that frame?

I think each toolbar should reflect the frame which contains it.

> 2 - Same thing goes for menus. All frames seem to get a common menu...
> even the main app window (which would be the DesktopPane in MDI mode).
> This seems a little redundant. Would we want each library to get its own
> menu? Are there certain menu items which belong only in the context of a
> library/scene frame or in the context of the main app frame? For
> example, perhaps cut/copy/paste shouldn't be in the main app frame (only
> in library and scene frames) while the "Preferences..." item would be
> only available in the main app frame?

I'm not sure I follow here.  In MDI mode, only the DesktopPane has a
menu since it is the only window. As far as I remember, there is no
main app frame in SDI mode.  Instead, each window is supposed to be
independent.  Why should I have to switch to some other window in
order to open the preferences?

SDI was designed for Mac OS X, where MDI does not exist.  Apple's UI
standards require that menu items be disabled instead of removed for
windows where they don't apply.  This way the user always knows where
to find a command, and has several other benefits.

[Jsynthlib-devel] Menu and toolbar question...

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

In SDI mode, each library/scene frame gets its own menu and can also
have its own toolbar. I've noticed a few things about this that raise
some UI questions:

1 - All of the toolbars seem to be the same instance. If I have multiple
libraries open with no patches selected in any of them, then the "cut"
and "copy" toolbuttons are greyed. If I select a patch in one of the
frames, the "cut" and "copy" toolbuttons are enabled on *all* of the
windows. Do we want this to happen, or should each frame have its own
toolbar that reflects the state of that frame?

2 - Same thing goes for menus. All frames seem to get a common menu...
even the main app window (which would be the DesktopPane in MDI mode).
This seems a little redundant. Would we want each library to get its own
menu? Are there certain menu items which belong only in the context of a
library/scene frame or in the context of the main app frame? For
example, perhaps cut/copy/paste shouldn't be in the main app frame (only
in library and scene frames) while the "Preferences..." item would be
only available in the main app frame?

- Joe

[Jsynthlib-devel] A change to JSLFrame, JSLDesktop, JSLProxy, JSLInternalProxyDesktopProxyFrameProxy....

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

Okay, I made that last one up...

I'm planning to change some of the workings of JSLFrame, JSLDesktop, and 
other related windowing parts of JSL. I think I can reduce the number of 
windowing classes by about 30%, reduce the lines of code in the classes 
by about 30%, and still not break anything.

Because JSL can operate in SDI or MDI mode, it needs to either use 
normal JFrames or JInternalFrames, depending upon which mode it's in. 
This presents a problem, since other JSL-specific frames (like 
PatchEditorFrame, for example) can't inherit from both. The current 
solution uses "proxies", where things like PatchEditorFrame ultimately 
inherit from JSLFrame... and JSLFrame avoids having to inherit from both 
by holding the JFrame or JInternalFrame as a data member (named 
"proxy"), and then passing every method call (like JSLFrame.repaint()) 
to the data member (ie, JSLFrame.repaint() would do nothing but call 
proxy.repaint()).

I've done this very thing before, but I've never seen it done to such a 
large scale as this. In its present state, even though I understand it 
now, I think it's very confusing and awkward. I *think* I can figure out 
a smoother way to do all of this. However, so that I don't break any of 
the existing code, I'm going to put it down in:
  org.jsynthlib.desktop
  org.jsynthlib.desktop.mdi
  org.jsynthlib.desktop.sdi

Now if you're wondering "Why? If it isn't broken, why fix it?". Well, 
because, although what's *there* works... it's difficult to *add* 
anything. It took me a couple of days, off and on, to figure out where 
to put the code for the application-frame icon. I also want to add a 
splash-screen for the initial load of JSL... but I'm at a loss for where 
to put it.

So, anyway, I don't expect to have this new thing working for a couple 
of weeks. So, don't panic. And, if it doesn't work at all, I just won't 
put it on the CVS. But I'm just letting you all know what I'm working on 
so that you can comment on it.

- Joe

Re: [Jsynthlib-devel] Difference between a scene and a patch....

[Daniel A. <dan...@us...>]

Hi Joe,

I think a scene enables you to put all your gear into a state which you nee=
d
for a certain track or set. That is, it holds all relevant patches and patc=
h
locations for one of your tracks or sets. It's something like a snapshot of
the state of the devices you manage with JSynthlib.

So, if you use JSynthlib to manage more than one device and use more than
one per track/set you will need multiple, different patches in a scene. The
menu entry Library -> "Transfer Scene" can then be used to transfer
everything to the devices in one go.

Cheers,
Daniel


On 2/24/06, Joe Emenaker <jo...@em...> wrote:
>
> It appears that a scene is just a patch that also has information about
> what bank/patch-location on the synth it's supposed to go to, is that
> correct?
>
> If that's the case, then I think we should incorporate this data into
> the normal Patch class (*after* we convert from serialization to XML for
> patch storage, of course). For normal Library frames, this info just
> wouldn't be displayed (but would still be kept and could be editable via
> a dialog box). Externally, this would allow seamless drag-n-drop between
> Scene frames and Library frames (right now, bank/patch info is lost when
> you drag from a SceneFrame to a LibraryFrame). Internally, it would
> clean up a lot of the cut-n-paste and drag-n-drop code. Right now, there
> are separate classes for dragging/pasting patches and scenes.
>
> This would also allow us to address one of Robert Wirski's issues from
> his mail back on the 20th:
> > A Bank/Patch number in the scene/librarian window is not set to the
> value it comes from, just to the first field in the list. It should point=
 to
> the same place by default.
> - Joe
>
>
>
>

[Jsynthlib-devel] Difference between a scene and a patch....

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

It appears that a scene is just a patch that also has information about 
what bank/patch-location on the synth it's supposed to go to, is that 
correct?

If that's the case, then I think we should incorporate this data into 
the normal Patch class (*after* we convert from serialization to XML for 
patch storage, of course). For normal Library frames, this info just 
wouldn't be displayed (but would still be kept and could be editable via 
a dialog box). Externally, this would allow seamless drag-n-drop between 
Scene frames and Library frames (right now, bank/patch info is lost when 
you drag from a SceneFrame to a LibraryFrame). Internally, it would 
clean up a lot of the cut-n-paste and drag-n-drop code. Right now, there 
are separate classes for dragging/pasting patches and scenes.

This would also allow us to address one of Robert Wirski's issues from 
his mail back on the 20th:
> A Bank/Patch number in the scene/librarian window is not set to the value it comes from, just to the first field in the list. It should point to the same place by default.
- Joe

[Jsynthlib-devel] jsynthlib on netbsd

[David G. <dg...@cs...>]

Has anyone here had any luck getting jsynthlib to work on netbsd?  I can't
seem to get even the loopback to work.

-- 
David Griffith
dg...@cs...

A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

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

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

As the first step toward getting the classes refactored into a sane 
package hierarchy, I have committed my changes to support saving patches 
to XML.

Here's the rundown:
 o For the time being, I'm using the jdom.jar library.... so you'll need 
to add jdom.jar to your classpath. Just look for any place where you 
have "groovy.jar" and change it to either "groovy.jar; jdom.jar" or 
"groovy.jar:jdom.jar". I don't remember if the "colon vs. semicolon" 
thing is platform-dependent.

 o Whenever you save any library (*just* libraries.... I haven't done 
scenes, yet), they are saved as the original "something.patchlib" file 
as well as "something.patchlib.xml".

 o When you load a file, you'll still be loading the original 
".patchlib" versions of your library. To change this, you need to open 
AbstractLibraryFrame and look for "void open(File file)". In that 
method, you'll see two boolean values: "readXMLFile" and "readOldFile". 
IF YOU MAKE BOTH OF THESE TRUE, YOU'LL GET TWO COPIES OF EACH PATCH! I 
did this so that you can load both versions at the same time and then 
open them both in a patch editor and see if there is any difference. 
Just be warned, however, that if you *save* the library after that, both 
the .patchlib and the .patchlib.xml will now have duplicates. So, if you 
load, save, load, save, etc. with both booleans set to "true", your 
library will double each time, and it will get really big really fast. I 
learned this the hard way. :)

 o The patch data is compressed via gzip and then converted to base64 
and then saved in the XML file. As a result, I've seen the XML file be 
anywhere from 10% to 50% the size of the .patchlib.

==== Things to think about while trying this ====

 o Right now, so that the XML file is closely associated with the 
.patchlib file, I've named it .patchlib.xml. What extension do we want 
to have permanently?

- Joe

[Jsynthlib-devel] Roland JD800 librarian and some comments

[<wi...@op...>]

Hello,
Roland JD800 librarian is ready and can be downloaded from www.jsynthlib.republika.pl/RolandJD800.zip. I would like also to share with you with my commentary on the JSynthLib. Firstly, I would like to propose to implement a function which allow us to create scene templates. I think there could be a button on a scene window like „save as template”, than we should be able to select „New Scene from template ...” from menu. It would save me a lot of time, really. I also wonder why single patch drivers do not allow to get edit buffers. It is my favorite type of work and saving edits to unit memories after every knob turning is tedious for me. I have included such an option in my JD800 driver. I understand that the JSynthLib uses edit buffers to examine/test patches only, so it would destroy the edits but it could be left up to a user to use such an option or not. Such things are found in commercial librarians (for example in SoundDiver) and I miss them a lot.
 There is also a small comment on the driver „get” option. A Bank/Patch number in the scene/librarian window is not set to the value it comes from, just to the first field in the list. It should point to the same place by default.
There is also an option which I dream about. The point is to have the ability to update a scene by pressing a button but also to revert to previous records, something like CVS. I have never seen such an option in any commercial librarian.
Sorry for my English.
Robert Wirski

Re: [Jsynthlib-devel] Fixing drag-n-drop

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

Joe Emenaker wrote:

>I noticed that drag-n-drop is enabled for the JTables in
>AbstractLibraryFrame. However, it seems to be fairly broken.
>  
>
I've found the problem. It turns out that basic drag-n-drop between
libraries was working like it was supposed to *except* the destination
table wasn't notified that its data had changed. So, if you dragged
something into the library, it wouldn't show up until you did something
else that triggered a fireTableChanged method, like minimizing/restoring
the library frame, adding a new patch, deleting a patch, etc. I've fixed
that.

However, there are three remaining items:
1 - Only COPY is supported with drag-n-drop right now. Is there any
opposition to also supporting MOVE?
2 - You can highlight multiple rows and then drag, but only one row gets
transferred. Do we want support for multiple-patch drag-n-drop?
3 - Right now, it appears that dragged patches are always appended to
the bottom of the table. Is there any interest in being able to drop
them between two existing rows?

- Joe

[Jsynthlib-devel] PatchContainer

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

It doesn't look like PatchContainer is used by any part of JSL. Can it
be removed?

- Joe

[Jsynthlib-devel] Fixing drag-n-drop

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

I noticed that drag-n-drop is enabled for the JTables in
AbstractLibraryFrame. However, it seems to be fairly broken.

Specifically:
1 - I wasn't able to drag from one library to another
2 - If I start to drag a patch and then place it back where I picked it
up from.... and *then* double-click anywhere in the table, the patch
that I had started to drag is pasted to the end of the library.
3 - Dragging a patch from one row in a library to another row fails to
overwrite the target row... *and* a double-click in the table pastes a
copy to the end of the table (like in item 2).

These all seem like broken behaviors to me. The correct behaviors, in my
opinion, would be:
2 - Draggin a patch and then placing it back where it came from should
remove the patch from the clipboard entirely. Also, double-clicking a
patch should never cause a paste.
3 - Dragging from one row to another should overwrite the target row.
Additionally, dragging from one row to a place off the end of the table
should create a new table entry with a copy.
1 - Dragging from one library/scene into another library/scene should
work, and the behaviors (in regards to replacement or appending of
patches) should be the same as the behavior mentioned for item 3.

Can anyone:
 1 - Confirm that I'm fairly correct in assessing the *current* behavior
of drag-n-drop in JSL, and
 2 - Offer their opinion on the bahvior changes I've proposed?

- Joe

Re: [Jsynthlib-devel] Two proposals

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

Rib Rdb wrote:
>> 2 - Is there a reason JSL *needs* to store all of the synthdriver info
>> in synthdriver.properties? Why can't we just discover them at runtime
>> like DeviceListWriter (or whatever it's called) does?
>>     
> Doesn't DeviceListWriter take a long time and cause a bunch of modal
> dialog boxes to pop up?
>   
I don't get any dialog boxes at all when I run it. Also, I just ran it 
via my IDE and it took about 2 seconds. It might take longer if you ran 
it from scratch and you had to load the JVM.... but running JSL does 
that anyway, so you're only adding a couple of seconds to the load time 
of JSL.

There are two motivations for this.

1 - First, I used to have enormous headaches when trying to generate a 
new synthdriver.properties file because, for some reason, with the IDE I 
use, the new synthdriver.properties file would get placed in the 
directory *above* where JSL would look for it when I ran the main GUI. 
Don't ask me why. I never figured out why. All I did was figure out that 
it was happening and now I manually copy the new synthdrivers.properties 
file every time I run DeviceListWriter.

2 - If we're ever going to support downloading new synthdrivers over the 
net (like Firefox or WinAmp support downloading new skins), then there 
has to be some way of dynamically adding synthdrivers *anyway*.

Plus, I'm planning on adding a start-up splashscreen and I could add a 
progress bar and a little text bar which said stuff like "loading 
synthdrivers", "loading settings", "starting GUI", etc... to make the 
wait less annoying.

- Joe

[Jsynthlib-devel] Two proposals

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

1 - Would anybody like to see JSL remember what libraries/scenes (and 
the window positions) they had open when they last exited JSL and 
re-open them the next time you run it? If so, does anybody have any 
suggestions for an XML format of storing this? If not, I'll use 
something like:
  <JSLSettings>
    <LastState>
      <Library Path="/home/jemenake/JSL/mylibrary.patchlib">
        <XPosition>40</XPosition>
        <YPosition>60</YPosition>
        <Width>400</Width>
        <Height>300</Height>
      </Library>
    </LastState>
  </JSLSettings>

2 - Is there a reason JSL *needs* to store all of the synthdriver info 
in synthdriver.properties? Why can't we just discover them at runtime 
like DeviceListWriter (or whatever it's called) does?

- Joe

Re: [Jsynthlib-devel] Conditional display of "What do you wish to do with the changed copy of the Patch?"

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

Thorsten Klose wrote:
> Btw.: A feature which I would like to see in this dialog box is a button, 
> which allows to save an edited patch to another bank location.
>   
Probably a good idea. However, in order to do this, we have to let the 
user specify the destination (which means some drop-down boxes). There 
are two ways to do this:
 1 - Have "Save", "Discard", "Save to other location" be *buttons* and, 
if the user chooses the last one, then they'd get *another* dialog box 
asking them where to save it.
 2 - Have "Save", "Discard", "Save to..." be radio-buttons and the 
drop-boxes will always be present, but disabled/greyed unless "Save 
to..." is selected.
> Currently it's required to copy & paste an existing patch to another
> location, before it can be modified without overwriting the old one.
>   
Actually, isn't this what "Save to clipboard" is for? You can save a 
copy to the clipboard and then paste into a bank someplace else?

- Joe

Re: [Jsynthlib-devel] Should compile now....

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

Daniel Appelt wrote:
> synthdrivers.AlesisSR16.DataModel which is used in 
> synthdrivers.Generic.HexDumpEditorFrame is still missing ;-)
Whoops. Sorry. Try it now...

Oh, and has anyone tried the bank printing, yet?

- Joe

Re: [Jsynthlib-devel] Should compile now....

[Daniel A. <dan...@us...>]

synthdrivers.AlesisSR16.DataModel which is used in
synthdrivers.Generic.HexDumpEditorFrame is still missing ;-)

Greetings,
Daniel


2006/2/7, Joe Emenaker <jo...@em...>:
>
> Okay, I think I fixed the problems from my commit two days ago that were
> preventing compiling.
>
> - Joe
>
>
>

Re: [Jsynthlib-devel] Standard ways of dealing with varying sysex formats

[Thorsten K. <Tho...@gm...>]

On Tuesday 07 February 2006 08:18, Joe Emenaker wrote:
> Granted, if I then sent this bank of sysex messages out to 
> the actual synth device, the device would receive the patches in a 
> non-sequential order... but I don't think the device has a problem with 
> that. However, I'm wondering if there's a "gotcha" to this method that 
> I'm overlooking.

I think that most synths, which provide a block access function, can also
handle with non-sequential accesses. It's like accessing EEPROMs or RAM, 
the patch and block number are just part of the memory address

Best Regards, Thorsten.

Re: [Jsynthlib-devel] Conditional display of "What do you wish to do with the changed copy of the Patch?"

[Thorsten K. <Tho...@gm...>]

Btw.: A feature which I would like to see in this dialog box is a button, 
which allows to save an edited patch to another bank location.

Currently it's required to copy & paste an existing patch to another
location, before it can be modified without overwriting the old one.

Best Regards, Thorsten.


On Monday 06 February 2006 17:39, Rib Rdb wrote:
> On 2/6/06, Joe Emenaker <jo...@em...> wrote:
> > As far as I can tell, PatchEditorFrame.frameClosing displays the "What
> > do you wish to do with the changed copy of the Patch?" dialog box
> > *regardless* of whether the patch data was edited at all. Is this correct?
> >
> > If it is, then am I the only one who thinks that PatchEditorFrame should
> > either compare the "before" and "after" data or there should be some
> > "patchWasChanged()" method in each synth's SingleDriver that it could
> > call to find out?
> 
> It looks like you are correct that the dialog is always displayed, and
> I agree that it should only be displayed if the patch was modified.
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
> 
> 

Re: [Jsynthlib-devel] Standard ways of dealing with varying sysex formats

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

On 2/6/06, Joe Emenaker <jo...@em...> wrote:
> Have the JSL developers, as a community, developed some standard ways of
> dealing with various sysex formats?
>
> For example, I've written a rudimentary driver for a device that
> transmits all of its patches in a single sysex message. For this type,
> if I want to move patches around in a bank, I have to move them around
> within that single sysex message.
>
> However, with a device I'm working on now, each patch is sent as roughly
> 8 smaller sysex messages. So, for a single patch, I'll have to deal with
> 8 separate sysex messages... each containing the settings for a certain
> aspect of that patch. Understandably, each of these sysex messages has
> to contain the patch number and parameter number of what they contain
> data for. So, conceivably, I could swap two patches by merely changing
> the patch numbers contained in the sysex messages themselves... in other
> words, never actually swapping the whole sysex messages to new
> locations. Granted, if I then sent this bank of sysex messages out to
> the actual synth device, the device would receive the patches in a
> non-sequential order... but I don't think the device has a problem with
> that. However, I'm wondering if there's a "gotcha" to this method that
> I'm overlooking.
>
> So, I thought I'd ask if the group has ever discussed (and possibly
> agreed upon) things like "When your synth device dumps it's patches in
> this way, we've found that the easiest way to handle those patches in
> JSL is to write your driver like this....".

Well, as far as I know, the only device so far to use multiple sysex
messages is the Yamaha Motif, and thus also the XML driver.  And
basically, the Motif is extremely complex so I've never finished an
editor or bank support for it.

Changing the patch number in the individual messages sounds like it
would work though.  But you'd probably want to somehow make sure that
you're not sending 2 or more patches to the same number. Maybe you
could keep an array of all the patches and move (rather than copy)
them to the correct position when changing the patch number (in
addition to changing the patch number in the message).  I'm not sure
if this helps though, as I said I've been waiting to look at Banks
until I have a fully functional Single driver.

[Jsynthlib-devel] Standard ways of dealing with varying sysex formats

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

Have the JSL developers, as a community, developed some standard ways of 
dealing with various sysex formats?

For example, I've written a rudimentary driver for a device that 
transmits all of its patches in a single sysex message. For this type, 
if I want to move patches around in a bank, I have to move them around 
within that single sysex message.

However, with a device I'm working on now, each patch is sent as roughly 
8 smaller sysex messages. So, for a single patch, I'll have to deal with 
8 separate sysex messages... each containing the settings for a certain 
aspect of that patch. Understandably, each of these sysex messages has 
to contain the patch number and parameter number of what they contain 
data for. So, conceivably, I could swap two patches by merely changing 
the patch numbers contained in the sysex messages themselves... in other 
words, never actually swapping the whole sysex messages to new 
locations. Granted, if I then sent this bank of sysex messages out to 
the actual synth device, the device would receive the patches in a 
non-sequential order... but I don't think the device has a problem with 
that. However, I'm wondering if there's a "gotcha" to this method that 
I'm overlooking.

So, I thought I'd ask if the group has ever discussed (and possibly 
agreed upon) things like "When your synth device dumps it's patches in 
this way, we've found that the easiest way to handle those patches in 
JSL is to write your driver like this....".

Well?

- Joe

[Jsynthlib-devel] Should compile now....

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

Okay, I think I fixed the problems from my commit two days ago that were 
preventing compiling.

- Joe