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

Re: [Jsynthlib-devel] Call for version 0.21

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

On Thu, Sep 8, 2011 at 8:59 AM, frankster <jsy...@te...>wrote:

> Do you think the refactoring is a candidate for 0.21 or are you going to
> hold off for the following release?
>

I posted a plan a few days ago:  0.21 as soon as possible, 0.22 etc as
changes accumulate.  Joe's refactor will be released as 0.30.

-Bill Zwicky

Re: [Jsynthlib-devel] Two refactoring questions

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

My first suggestion is to move all source code into /src.  Optionally,
synthdrivers can be move to /src-synthdrivers or just /synthdrivers in
preparation for the plugin framework.  Synths should be repackaged as well,
so the final directory will actually be
/synthdrivers/org/jsynthlib/synthdrivers/*.

On Thu, Sep 8, 2011 at 9:30 AM, Joe Emenaker <jo...@em...> wrote:

>
> 1 - When I move all of the stuff from "core" into "org.jsynthlib", how
> should it be organized? I'm planning all of the "*ConfigPanel" stuff
> moving into org.jsynthlib.config, and probably all of "*Widget" going
> into org.jsynthlib.widget. Things like Base64 and XMLFileUtils probably
> going into org.jsynthlib.utils. There's a lot more stuff, however, that
> needs a home. Any suggestions for further categorization are welcome.
> I'm thinking that we might also want a dedicated package for the classes
> which the synthdrivers use for superclasses (ie, PatchEditorFrame,
> LibraryFrame, BankEditorFrame, etc.). I've come across some synthdrivers
> which were subclassing some fairly strange frames... possibly because
> they were the first ones that they came across which seemed like they'd
> work or something.
>

These are all excellent ideas.  I might suggest an 'app' package for the
main JSynthLib app, windows, menus, etc.

2 - Some of the classes have their *type* implied in the name. For
> example, there's an abstract class called "AbstractLibraryFrame" and
> there are some interfaces called "IDriver" and "IBankPatch". These
> aren't really the way the base Java libraries do it and, personally, I
> find it confusing (I keep asking myself "What the heck is an 'abstract
> library'?"). My preference would be to rename AbstractLibraryFrame to
> just LibraryFrame, and IDriver to just Driver, etc. Any objections?
>

I agree.  I myself favor systems like "interface Driver" and "abstract class
DriverBase".  The system is then carefully coded to only require Driver so
people can write fully custom implementations, but DriverBase is available
as a starting point.

I understand the reasoning behind names like IDriver and CDriver, but I
always need the docs around when I code, so I've never found that trick
useful.

-Bill Zwicky

[Jsynthlib-devel] Two refactoring questions

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

Just wanted to get some opinions/preferences from the group:

1 - When I move all of the stuff from "core" into "org.jsynthlib", how 
should it be organized? I'm planning all of the "*ConfigPanel" stuff 
moving into org.jsynthlib.config, and probably all of "*Widget" going 
into org.jsynthlib.widget. Things like Base64 and XMLFileUtils probably 
going into org.jsynthlib.utils. There's a lot more stuff, however, that 
needs a home. Any suggestions for further categorization are welcome. 
I'm thinking that we might also want a dedicated package for the classes 
which the synthdrivers use for superclasses (ie, PatchEditorFrame, 
LibraryFrame, BankEditorFrame, etc.). I've come across some synthdrivers 
which were subclassing some fairly strange frames... possibly because 
they were the first ones that they came across which seemed like they'd 
work or something.

2 - Some of the classes have their *type* implied in the name. For 
example, there's an abstract class called "AbstractLibraryFrame" and 
there are some interfaces called "IDriver" and "IBankPatch". These 
aren't really the way the base Java libraries do it and, personally, I 
find it confusing (I keep asking myself "What the heck is an 'abstract 
library'?"). My preference would be to rename AbstractLibraryFrame to 
just LibraryFrame, and IDriver to just Driver, etc. Any objections?

- Joe

Re: [Jsynthlib-devel] Call for version 0.21

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

On 9/8/2011 8:59 AM, frankster wrote:
> On 09/08/11 16:44, Joe Emenaker wrote:
>>    SVN, I'm told, *does*
>> support moving, so it's my hope that this will preserve the revision
>> history when the files get moved.
> svn mv core/X  org/jsynthlib/X

Yup. It's just a matter of "svn diff" sees "deeply" through moves, I 
guess...

> Do you think the refactoring is a candidate for 0.21 or are you going 
> to hold off for the following release?

No way for 0.21. A lot of the UI code has been moved around or 
re-written. I haven't been able to test any of it because it won't even 
compile from all of the stuff I'm changing. I might have it compiling by 
the end of today, but I'm anticipating lots of little UI glitches (like, 
windows not moving to the front when they're supposed to, or not 
notifying xyz when they're closed, etc) which will require that the 
refactored build just get used a bit so we can find all of the little 
things I messed up during the re-write.

- Joe

Re: [Jsynthlib-devel] Call for version 0.21

[frankster <jsy...@te...>]

On 09/08/11 16:44, Joe Emenaker wrote:
>   SVN, I'm told, *does*
> support moving, so it's my hope that this will preserve the revision
> history when the files get moved.
svn mv core/X  org/jsynthlib/X
> - When I saw how many synthdrivers and other UI components were
> subclassing Actions.MenuFrame, I freaked and decided to un-tangle that
> mess... which is what I'm just finishing up now.
>
> If I move files around while I'm working in branches/UIRefactor, then
> that's going to create chaos when we try to merge this into trunk. So,
> I'm not going to move any existing files until *after* the merge to
> trunk, but they *will* move after that and everything will look a lot
> cleaner.

sounds good.

Do you think the refactoring is a candidate for 0.21 or are you going to 
hold off for the following release?

frankie

Re: [Jsynthlib-devel] Fwd: [Jsynthlib-cvs] SF.net SVN: jsynthlib:[1104] trunk/JSynthLib/core/Actions.java

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

On 9/8/2011 8:13 AM, frankster wrote:
> What about if the midi layer will never queue more than 1 message from 
> a particular widget (so the midi layer would have to track the source 
> of each message) and if multiple messages appeared from the same 
> widget's Sender class, it would discard all but the most recent.

This strikes me as a great way to do it. We could even do it without the 
widget losing its place in the queue. We could just replace the old 
message with the new one.

I'm not troubled by the fact that the midi layer would need to track the 
source. That seems like we could do some handy things with that kind of 
info down the road.

> This would mean that widget messages have to be stateless and 
> interchangeable. Is this a reasonable condition? It is on the 
> synths/drivers i've played with but I can't speak for most of them.

We could let each synthdriver decide their own queue policy (ie, only 
hold one message per widget, or hold all of them). A more-complicated 
solution would be for widgets to indicate which messages belong as a 
set... but I don't see a need for that.

- Joe

Re: [Jsynthlib-devel] Call for version 0.21

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

On 9/8/2011 3:10 AM, William Zwicky wrote:
> Note that I don't have permissions to post a binary, so we'll need a
> volunteer for that.  And if you'd prefer to be the one to BUILD the binary,
> let me know.

I can probably post the binary, but I probably shouldn't build it. I 
don't use ant or make or any of the tools which use the build.xml and 
other files which everybody carefully maintains.

> If you're working on something now, please respond with an estimate of how
> long it'll take (powers of ten - 1, 10, 100 days).

Well, while you're talking about releases, I want to mention something 
else about the refactor (now that I'm diving back into the code and 
remembering what the hell I was thinking at the time). The *original* 
refactoring plan was to make "core" go away, entirely. Everything in 
core was going to get neatly organized into org.jsynthlib somehow. Two 
things postponed this:
- CVS (which is what sourceforge was using at the time) didn't support 
"moving" files across directories. When they got moved, CVS would treat 
them as one file being deleted and another, unrelated one being added. 
This would affect people's ability to see diffs between versions on 
either side of the date when the file was moved. SVN, I'm told, *does* 
support moving, so it's my hope that this will preserve the revision 
history when the files get moved.
- When I saw how many synthdrivers and other UI components were 
subclassing Actions.MenuFrame, I freaked and decided to un-tangle that 
mess... which is what I'm just finishing up now.

If I move files around while I'm working in branches/UIRefactor, then 
that's going to create chaos when we try to merge this into trunk. So, 
I'm not going to move any existing files until *after* the merge to 
trunk, but they *will* move after that and everything will look a lot 
cleaner.

- Joe

Re: [Jsynthlib-devel] Fwd: [Jsynthlib-cvs] SF.net SVN: jsynthlib:[1104] trunk/JSynthLib/core/Actions.java

[Vladimir A. <vl...@gm...>]

On 09/08/2011 04:31 AM, frankster wrote:
> Can anyone think of anything simpler that would do the job? Although one
> advantage of this is that it would
> keep the driver simple, and all the complexity would be in core base
> classes.
>

Well, i can think of something more complicated, but maybe more universal.

So the idea is that synth driver would register with core each kind of 
midi message it is going to send. During registration it specifies max 
rate or processing time for each message.

Also it specifies the type - only last message of the kind shall be 
sent, or all queued messages of the kind shall be sent. Also maybe 
priority with respect to other messages.

Then the drivers submit messages for sending to core in any order at any 
rate.

The core maintain the queues for each registered kind of message. When 
the interface is available, the core selects among the queues next 
message, send it and blocks the sending for time specified at registration.


-- 
Vladimir

Re: [Jsynthlib-devel] Fwd: [Jsynthlib-cvs] SF.net SVN: jsynthlib:[1104] trunk/JSynthLib/core/Actions.java

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

On 9/8/2011 3:01 AM, William Zwicky wrote:
> What if the delay depends on the nature of the change? Maybe parameter 
> changes are no problem, but those huge patch sets take a few seconds 
> to digest. It might be possible to send a request that is only 
> answered when the synth is done, or you might have to just set a 3 
> second timer and hope. The sender could then store the latest value 
> received from the widget

Now it's getting trickier. My initial thought is that something like 
this should be handled in the synthdriver, because it's not an issue in 
*transferring* the data over the MIDI wires. See what I'm saying? 
There's the limit that the synth has in how many bytes per second it can 
gobble from the wires (which would be managed by the MIDI layer) and 
then there's any extra time that the synth needs to digest the data once 
it has been received. That second category might be best managed in the 
synthdriver.

> Yeah, that's pretty much it.  When a parameter changes but we cannot send,
> we save the new value, and set a flag.  When an opportunity to send arrives,
> we scan for those flags and send the first one we find.  But even this may
> be synth-dependent -- if multiple params change, I may want to build a
> single message that updates them all at once.

Well, in the idea that I posed in my previous post, the MIDI layer would 
just accept changes until it decided that the queue was full and, when 
it was full, it would just throw exceptions to the widgets. The widgets 
would have the option to tell the MIDI layer to purge all other queued 
messages from the widget, etc. However, if it's the case that some 
synths support sysex message which update multiple parameters at once, 
then I can see the rationale for letting the widgets inspect all of 
their queued messages and then trading them out of a consolidated one.

I can't think of a slick way of preserving their place in the queue, 
though. They'd either go right to the front of the queue or to the end.

- Joe

Re: [Jsynthlib-devel] Fwd: [Jsynthlib-cvs] SF.net SVN: jsynthlib:[1104] trunk/JSynthLib/core/Actions.java

[frankster <jsy...@te...>]

On 09/08/11 16:01, Joe Emenaker wrote:
> On 9/8/2011 2:31 AM, frankster wrote:
>> Can anyone think of anything simpler that would do the job? Although one
>> advantage of this is that it would
>> keep the driver simple, and all the complexity would be in core base
>> classes.
> I'm thinking this:
> - There should be a application-wide rate limit on how often widgets
> send updates when the user is moving them. This limit would be able to
> be set by the user. It would *always* send when the user releases the
> widget, but they could also ask for updates to be sent X times per
> second... or whenever the control has moved another X% of the entire
> range since the last send.
This sounds reasonable.
> - Widgets would be ignorant of any rate limit imposed by the individual
> synths. The MIDI layer would know about them, and it would queue up and
This is a sensible division of responsibility I think.
> throttle outbound messages. If the outgoing queue ever got too full (ie,
> we don't want the MIDI layer queuing up 30 seconds of widget updates),
> then it would throw some exception. The widgets would decide how to deal
> with the exception. They could just discard the latest update they
> wanted to send, or they could possibly tell the MIDI layer something
> like "Discard all of the pending updates from me that you've got queued,
> and just send this one".

What about if the midi layer will never queue more than 1 message from a 
particular widget (so the midi layer would have to track the source of 
each message) and if multiple messages appeared from the same widget's 
Sender class, it would discard all but the most recent.

This would mean that widget messages have to be stateless and 
interchangeable. Is this a reasonable condition? It is on the 
synths/drivers i've played with but I can't speak for most of them.

frankie

Re: [Jsynthlib-devel] Fwd: [Jsynthlib-cvs] SF.net SVN: jsynthlib:[1104] trunk/JSynthLib/core/Actions.java

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

On 9/8/2011 2:31 AM, frankster wrote:
> Can anyone think of anything simpler that would do the job? Although one
> advantage of this is that it would
> keep the driver simple, and all the complexity would be in core base
> classes.

I'm thinking this:
- There should be a application-wide rate limit on how often widgets 
send updates when the user is moving them. This limit would be able to 
be set by the user. It would *always* send when the user releases the 
widget, but they could also ask for updates to be sent X times per 
second... or whenever the control has moved another X% of the entire 
range since the last send.
- Widgets would be ignorant of any rate limit imposed by the individual 
synths. The MIDI layer would know about them, and it would queue up and 
throttle outbound messages. If the outgoing queue ever got too full (ie, 
we don't want the MIDI layer queuing up 30 seconds of widget updates), 
then it would throw some exception. The widgets would decide how to deal 
with the exception. They could just discard the latest update they 
wanted to send, or they could possibly tell the MIDI layer something 
like "Discard all of the pending updates from me that you've got queued, 
and just send this one".

- Joe

Re: [Jsynthlib-devel] Fwd: [Jsynthlib-cvs] SF.net SVN: jsynthlib:[1104] trunk/JSynthLib/core/Actions.java

[frankster <jsy...@te...>]

On 09/08/11 15:22, Joe Emenaker wrote:
> On 9/7/2011 10:54 PM, William Zwicky wrote:
>> I worry that for some synths, the rate limiting is synth-specific.  Is there
>> (or are you thinking of) a framework to plug rate limiting into?  Or would
>> we need to implement a layer on top of sendSysex()?
> It has been a while since I worked on the raw MIDI subsystem. But this
> is what I was thinking:
> - It should be possible for individual synths to tell the MIDI layer
> their maximum speed. The MIDI layer probably knows what interface
> they're on (and could also know what synth they're sending a message on
> behalf of), so... if we're lucky, the speed would only be throttled for
> message to that specific synth. If we're not lucky, speed would be
> limited for that whole interface.
> - Even if we *are* lucky and can limit the speed based upon the synth,
> there should *also* be a way for a synth to ask that the entire
> interface be speed-limited. This would be in cases where, even though
> the sysex (or other MIDI) traffic is not *targeted* to the slow synth,
> the slow synth still locks up when it sees the traffic going by.

Yeah it might turn out that a number of devices have to process all midi 
messages on the port regardless of who the message is addressed to.

> - This would not be something we'd add to sendSysex(). We'd just add
> some new method in the MIDI layer for synthdrivers to ask for
> speed-limiting once and the MIDI layer would just honor that until it
> was asked for a new speed limit.
>
>> As for UI controls, we definitely need a smart system for that.  If the user
>> drags a slider from 0 to 100, we don't want to send 100 updates, just the
>> few we actually have time for.
> Oh, wow... you're right. That's a dicey problem. We'd kinda want to
> either have the widget not send an update when the user is moving the
> widget *fast*, but then, when they got close, to start sending then...

If this was a live performance system it would be a critical issue 
getting smooth fader slides etc, however its just a patch editor, so 
possibly something as basic as "no control may update more often than 
every 100ms" could work well enough for our purposes across many devices.

> or maybe only send when they released the widget. Actually, we probably
> want the user to indicate how "eager" the widgets are with some setting
> in the control panel.
>
> - Joe
>
I don't know if this is something the user should have to fiddle with - 
ideally we should be able to work it out once for each device, register 
the setting with the midi layer, and then get it right in perpetuity.

cheers,
Frankie

Re: [Jsynthlib-devel] Fwd: [Jsynthlib-cvs] SF.net SVN: jsynthlib:[1104] trunk/JSynthLib/core/Actions.java

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

On 9/7/2011 10:54 PM, William Zwicky wrote:
> I worry that for some synths, the rate limiting is synth-specific.  Is there
> (or are you thinking of) a framework to plug rate limiting into?  Or would
> we need to implement a layer on top of sendSysex()?

It has been a while since I worked on the raw MIDI subsystem. But this 
is what I was thinking:
- It should be possible for individual synths to tell the MIDI layer 
their maximum speed. The MIDI layer probably knows what interface 
they're on (and could also know what synth they're sending a message on 
behalf of), so... if we're lucky, the speed would only be throttled for 
message to that specific synth. If we're not lucky, speed would be 
limited for that whole interface.
- Even if we *are* lucky and can limit the speed based upon the synth, 
there should *also* be a way for a synth to ask that the entire 
interface be speed-limited. This would be in cases where, even though 
the sysex (or other MIDI) traffic is not *targeted* to the slow synth, 
the slow synth still locks up when it sees the traffic going by.
- This would not be something we'd add to sendSysex(). We'd just add 
some new method in the MIDI layer for synthdrivers to ask for 
speed-limiting once and the MIDI layer would just honor that until it 
was asked for a new speed limit.

> As for UI controls, we definitely need a smart system for that.  If the user
> drags a slider from 0 to 100, we don't want to send 100 updates, just the
> few we actually have time for.

Oh, wow... you're right. That's a dicey problem. We'd kinda want to 
either have the widget not send an update when the user is moving the 
widget *fast*, but then, when they got close, to start sending then... 
or maybe only send when they released the widget. Actually, we probably 
want the user to indicate how "eager" the widgets are with some setting 
in the control panel.

- Joe

Re: [Jsynthlib-devel] Fwd: [Jsynthlib-cvs] SF.net SVN: jsynthlib:[1104] trunk/JSynthLib/core/Actions.java

[frankster <jsy...@te...>]

On 09/08/11 11:01, William Zwicky wrote:
> On Thu, Sep 8, 2011 at 2:31 AM, frankster<jsy...@te...>wrote:
>
>> (just have each driver register a max amount per time frame it can handle).
>>
> What if the delay depends on the nature of the change?   Maybe parameter
> changes are no problem, but those huge patch sets take a few seconds to
> digest.  It might be possible to send a request that is only answered when
> the synth is done, or you might have to just set a 3 second timer and hope.

Perhaps there are two classes of sysex/controller data to consider -
bulk dump and real-time patch change - and they can't be handled
the same.

>
> The sender could then store the latest value received from the widget
>> for a parameter, then check with
>> this central rate tracker whether its allowed to send or not, and if its
>> not allowed to send then it stores
>> the widget value and requests notification from the central rate tracker
>> when it would be ok to send.
>> In the meantime if any additional widget events come in before the
>> notification, they can store their values
>> too. Finally the notification comes through from the central rate
>> tracker and it sends it.
>>
>> Its getting a bit complicated because maybe if two widgets were modified
>> in close succession we might
>> need a queue of notifications so that we don't miss out on one widget
>> update because it was drowned
>> out by another.
>>
> Yeah, that's pretty much it.  When a parameter changes but we cannot send,
> we save the new value, and set a flag.  When an opportunity to send arrives,
> we scan for those flags and send the first one we find.  But even this may
> be synth-dependent -- if multiple params change, I may want to build a
> single message that updates them all at once.

Maybe the synths Sender subclass could handle this if it gets a notification
  - check with the other sender instances and decide whether it wants to
  send 2 controller changes or re-dump the patch or whatever.

> The only alternative I can think of is to defer the high-level layer, and
> instead try these tricks with individual synths.  After that, we can hunt
> for commonalities, and implement a higher-level layer.
>

Yeah no point implementing a high level layer until the low level details
are well understood by all involved - I probably haven't written enough 
drivers
yet to be an expert on flow control issues. But its definitely worth having
flow control in the back of our minds as we do other things.

My current plan of action is:
* M350 driver (nearly done)
* U220 driver (if I can work out what the manual is on about)
* Keystation Pro 88 driver
* Proteus 2000 family driver - this is a big one
Assuming I make it this far, then this might be the time when I would be 
ready to
think about rate limiting.

frankie

Re: [Jsynthlib-devel] Call for version 0.21

[frankster <jsy...@te...>]

On 09/08/11 11:10, William Zwicky wrote:
> If you're working on something now, please respond with an estimate of how
> long it'll take (powers of ten - 1, 10, 100 days).
>

TC Electronic M350 Effect Unit driver, should be ready in about 1 day.

frankie

[Jsynthlib-devel] Call for version 0.21

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

I'd like to call for a focused effort to build a new release within no more
than a few weeks.  Things that are clear and simple and can be done within a
few days should be wrapped up so we can release.  If you're working on
bigger things (like a whole new synth driver) and you expect to take a few
weeks, then we'll hold that back for 0.22.

Note that I don't have permissions to post a binary, so we'll need a
volunteer for that.  And if you'd prefer to be the one to BUILD the binary,
let me know.

If you're working on something now, please respond with an estimate of how
long it'll take (powers of ten - 1, 10, 100 days).

-Bill Zwicky

Re: [Jsynthlib-devel] Fwd: [Jsynthlib-cvs] SF.net SVN: jsynthlib:[1104] trunk/JSynthLib/core/Actions.java

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

On Thu, Sep 8, 2011 at 2:31 AM, frankster <jsy...@te...>wrote:

> (just have each driver register a max amount per time frame it can handle).
>

What if the delay depends on the nature of the change?   Maybe parameter
changes are no problem, but those huge patch sets take a few seconds to
digest.  It might be possible to send a request that is only answered when
the synth is done, or you might have to just set a 3 second timer and hope.

The sender could then store the latest value received from the widget
> for a parameter, then check with
> this central rate tracker whether its allowed to send or not, and if its
> not allowed to send then it stores
> the widget value and requests notification from the central rate tracker
> when it would be ok to send.
> In the meantime if any additional widget events come in before the
> notification, they can store their values
> too. Finally the notification comes through from the central rate
> tracker and it sends it.
>
> Its getting a bit complicated because maybe if two widgets were modified
> in close succession we might
> need a queue of notifications so that we don't miss out on one widget
> update because it was drowned
> out by another.
>

Yeah, that's pretty much it.  When a parameter changes but we cannot send,
we save the new value, and set a flag.  When an opportunity to send arrives,
we scan for those flags and send the first one we find.  But even this may
be synth-dependent -- if multiple params change, I may want to build a
single message that updates them all at once.

Can anyone think of anything simpler that would do the job? Although one
> advantage of this is that it would
> keep the driver simple, and all the complexity would be in core base
> classes.
>

The only alternative I can think of is to defer the high-level layer, and
instead try these tricks with individual synths.  After that, we can hunt
for commonalities, and implement a higher-level layer.

-Bill Zwicky

Re: [Jsynthlib-devel] Fwd: [Jsynthlib-cvs] SF.net SVN: jsynthlib:[1104] trunk/JSynthLib/core/Actions.java

[frankster <jsy...@te...>]

On 08/09/2011 06:54, William Zwicky wrote:
> On Wed, Sep 7, 2011 at 6:28 AM, frankster <jsy...@te...>wrote:
>
>> On 09/06/11 19:15, Joe Emenaker wrote:
>>> Oooh. A rate-limited "sendSysex()" or something could be a good addition.
>> It might need to be a little more complicated than just sendSysex(),
>> because I think the UI controls could send quite a lot of messages out
>> if you changed them quite frequently.
>>
> I worry that for some synths, the rate limiting is synth-specific.  Is there
> (or are you thinking of) a framework to plug rate limiting into?  Or would
> we need to implement a layer on top of sendSysex()?

Maybe the Sender base class that we already use with the widgets can do
this for us without having
to write plugins (just have each driver register a max amount per time
frame it can handle).
For example if we have something centrally tracking the rate of data
that has recently been sent to a
device or a midi port (and each driver can register how much data in
what time frame its device can handle),

The sender could then store the latest value received from the widget
for a parameter, then check with
this central rate tracker whether its allowed to send or not, and if its
not allowed to send then it stores
the widget value and requests notification from the central rate tracker
when it would be ok to send.
In the meantime if any additional widget events come in before the
notification, they can store their values
too. Finally the notification comes through from the central rate
tracker and it sends it.

Its getting a bit complicated because maybe if two widgets were modified
in close succession we might
need a queue of notifications so that we don't miss out on one widget
update because it was drowned
out by another.

Can anyone think of anything simpler that would do the job? Although one
advantage of this is that it would
keep the driver simple, and all the complexity would be in core base
classes.

>
> As for UI controls, we definitely need a smart system for that.  If the user
> drags a slider from 0 to 100, we don't want to send 100 updates, just the
> few we actually have time for.

yeah my tx81z definitely can't handle all these ui events and I don't
think the TC M350 can either even though
its much more modern. ;) Should have the driver ready for this later
tonight actually

frankie

Re: [Jsynthlib-devel] Fwd: [Jsynthlib-cvs] SF.net SVN: jsynthlib:[1104] trunk/JSynthLib/core/Actions.java

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

On Wed, Sep 7, 2011 at 6:28 AM, frankster <jsy...@te...>wrote:

> On 09/06/11 19:15, Joe Emenaker wrote:
> > Oooh. A rate-limited "sendSysex()" or something could be a good addition.
> It might need to be a little more complicated than just sendSysex(),
> because I think the UI controls could send quite a lot of messages out
> if you changed them quite frequently.
>

I worry that for some synths, the rate limiting is synth-specific.  Is there
(or are you thinking of) a framework to plug rate limiting into?  Or would
we need to implement a layer on top of sendSysex()?

As for UI controls, we definitely need a smart system for that.  If the user
drags a slider from 0 to 100, we don't want to send 100 updates, just the
few we actually have time for.

-Bill Zwicky

Re: [Jsynthlib-devel] Fwd: [Jsynthlib-cvs] SF.net SVN: jsynthlib:[1104] trunk/JSynthLib/core/Actions.java

[frankster <jsy...@te...>]

On 09/06/11 19:15, Joe Emenaker wrote:
>> The TX81z seems to have a hardware limitation whereby an error message
>> can appear on its screen talking about its midi message buffer being
>> full. I am assuming this is because there needs to be some kind of rate
>> limit on messages sent to it.
> Oooh. A rate-limited "sendSysex()" or something could be a good addition.
It might need to be a little more complicated than just sendSysex(), 
because I think the UI controls could send quite a lot of messages out 
if you changed them quite frequently.

Re: [Jsynthlib-devel] Can't figure out how to branch...

[Vladimir A. <vl...@gm...>]

On 09/06/2011 11:20 PM, Joe Emenaker wrote:
> On 9/6/2011 3:04 PM, Joachim wrote:
>> >  Hi Joe,
>> >
>> >  according to the CVS-list it worked now.
>> >  Can you tell us the commands you used?
> Well, you're going to be a bit disappointed.
>

So I was trying to figure out what might be wrong with linux command 
line and along the way just created branch from needed revision, which 
you may keep, or may delete and create anew, if my report would help you 
resolve your problem.

When using https access from command line I was getting first prompt for 
gnome keyring, and then authentication error:

--------------------------------------------
Password for '(null)' GNOME keyring:
svn: MKACTIVITY of 
'/svnroot/jsynthlib/!svn/act/7f22cffe-6d97-4efb-8504-4731f86db06f': 
authorization failed: Could not authenticate to server: rejected Basic 
challenge (https://jsynthlib.svn.sourceforge.net)
--------------------------------------------

Well, I do not have complete gnome installed, so I went to edit 
~/.subversion.config and changed this:

password-stores = gnome-keyring, kwallet

to this:

password-stores = kwallet

After doing that the following commands first asked me for password to 
kde password store, then for my SF username and password, and everything 
worked as expected. Exact commands were (spelling of original, sorry for 
leaving misspelled messages, I wish there was a spell checker in console):

------------------------------------------------
svn copy 
https://jsynthlib.svn.sourceforge.net/svnroot/jsynthlib/trunk/JSynthLib 
https://jsynthlib.svn.sourceforge.net/svnroot/jsynthlib/branches/UIRefactor 
-r 1051 -m "Refactoring effor by Joe Emenaker"

svn del 
https://jsynthlib.svn.sourceforge.net/svnroot/jsynthlib/branches/UIRefactor-jemenake 
-m "Branch cretaed from wrong revision, correct revision used for 
branches/UIRefactor, removing this as unneeded"
------------------------------------------------

-- 
Vladimir

Re: [Jsynthlib-devel] Can't figure out how to branch...

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

On 9/6/2011 3:04 PM, Joachim wrote:
> Hi Joe,
>
> according to the CVS-list it worked now.
> Can you tell us the commands you used?

Well, you're going to be a bit disappointed.

First, I used the Subversion tool in Jetbrains IDEA. So, I didn't use 
command-line.

Next, if you look closely, you'll notice that *my* copy doesn't have a 
"JSynthLib" folder directly beneath the root, it starts with the 
*contents* of the JSynthLib folder. So, I copied from a level deeper 
than everybody else does. This isn't really a problem if I'm the only 
one using the branch, but it was still a mistake.

Lastly, I forgot to tell the tool to copy rev 1051, so it copied the 
latest revision. I can't use that. So, now, I'm trying to figure out how 
to delete that and do it over. The Jetbrains tool doesn't have a delete 
function. The linux svn tool keeps telling me that it's going to ignore 
that command from the list it's actually going to execute. And 
Soureforge's web interface doesn't offer it, either. I may have to 
install Tortoise, but I really want to see why the linux svn tool is 
failing for any command that requires authentication/credentials.

- Joe

Re: [Jsynthlib-devel] mysterious manufacturer ID!

[frankster <jsy...@te...>]

Nice find - that guy is using a Keystation Pro 88 and I have this
keyboard, so this pretty much proves the device ID is coming from the
keyboard.

thanks.

On 06/09/2011 22:03, Narfman96 - Narfland Studio wrote:
> Hi Guys!!!! Glad to see the project back up and active... I'm a long time lurker and JSynthLib user. I'm not a programmer by any means but I help out when I can.
>  
> To support what you found the 00H 20H 08H sysex ID for a Keystation midi controller is mentioned on this Linux site:  http://www.spinics.net/linux/fedora/alsa-user/msg01813.html
>  
> Also I know the extended sysex ID list is missing current ID's because Novation's is 00H 20H 29H and it's not included.
>  
> Good luck with all your hard work. Hi Joe and Joachim!   Fran
> ------------------------------------------------------------------------------
> Malware Security Report: Protecting Your Business, Customers, and the 
> Bottom Line. Protect your business and customers by understanding the 
> threat from malware and how it can impact your online business. 
> http://www.accelacomm.com/jaw/sfnl/114/51427462/
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel

Re: [Jsynthlib-devel] Can't figure out how to branch...

[Joachim <li...@sd...>]

Hi Joe,

according to the CVS-list it worked now.
Can you tell us the commands you used?

Cheers
Joachim

Am 06.09.2011 18:19, schrieb Joe Emenaker:
>
> I'm such a SVN n00b...
>
> I can't make a branch for my refactor. When I try it from the command
> line on my Ubuntu box, I do...
>
>> svn copy
>> https://jsynthlib.svn.sourceforge.net/svnroot/jsynthlib/trunk@r1051
>> https://jsynthlib.svn.sourceforge.net/svnroot/jsynthlib/branches/UIRefactor-jemenake
>> --username blahblahblah --password blahblahblah
>
> to try to copy release 1051 to a branch called "UIRefactor-jemenake"
> (because my changes are all based off of r1051).
>
> When  I try to do this, however, SVN tells me that the second URL is
> going to be ignored, and then gives me the option to abort/continue/edit.
>
> Do I have to make the branch in the SourceForge web interface or something?
>
> - Joe
>
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>

Re: [Jsynthlib-devel] mysterious manufacturer ID!

[Narfman96 - N. S. <nar...@ya...>]

Hi Guys!!!! Glad to see the project back up and active... I'm a long time lurker and JSynthLib user. I'm not a programmer by any means but I help out when I can.
 
To support what you found the 00H 20H 08H sysex ID for a Keystation midi controller is mentioned on this Linux site:  http://www.spinics.net/linux/fedora/alsa-user/msg01813.html
 
Also I know the extended sysex ID list is missing current ID's because Novation's is 00H 20H 29H and it's not included.
 
Good luck with all your hard work. Hi Joe and Joachim!   Fran