On Thu, Sep 8, 2011 at 8:59 AM, frankster 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.
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/
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.widg
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 "deepl
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.MenuFram
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
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
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 mo
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 mi
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:
>
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 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()?
>
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 ra
On 09/08/11 11:01, William Zwicky wrote:
> On Thu, Sep 8, 2011 at 2:31 AM, franksterwrote:
>
>> (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 se
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
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
On Thu, Sep 8, 2011 at 2:31 AM, frankster 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 po
On 08/09/2011 06:54, William Zwicky wrote:
> On Wed, Sep 7, 2011 at 6:28 AM, frankster
> 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(),
>> becau
18 matches
Mail list logo
