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

Re: [Jsynthlib-devel] 10th anniversary

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

On 09/23/11 13:59, Roger Westerlund wrote:
> 2011/9/23 Frankie Fisher<jsy...@te...>:
>
>> On the subject of confusion, its not immediately obvious to a first time
>> user what the difference between a library and a scene is, so in the
>> long run we definitely need to either come up with a method of teaching
>> the first time user, or possibly change how it works.
> That is exactly the thing I was confused over. I still don't know what
> a Scene is for (yes, I am embarrassed now).
>
> Just by having a slightly different visual appearance between them
> would at least show that they are not the same (they are not, are
> they?). :-)
>
> / Roger
maybe they could even be merged; i dunno. From the docs (which have 
fallen off the internet in the last couple of days!): "The advantage of 
a scene is that it contains the locations for the patches in the synth's 
memories in addition to the patches themselves"

So a scene has more to do with a particular synth's setup. It does sound 
useful - though I have to confess I've only really used libraries so far.

frankie

[Jsynthlib-devel] jsynthlib.org expired in the last couple of days!

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

If you go to jsynthlib.org it redirects to a tucows domain expiry page.

It had loads of good info on there so before the 0.21 release we could 
do with either getting it back online, or alternatively mirroring all 
the docs from it elsewhere.

frankie

Re: [Jsynthlib-devel] 10th anniversary

[Frankie F. <jsy...@te...>]

On 23/09/2011 09:05, Roger Westerlund wrote:
> 2011/9/23 William Zwicky <wrz...@po...>:
>> On Thu, Sep 22, 2011 at 11:34 PM, Roger Westerlund <
>> ro...@us...> wrote:
>>
>>> Me myself is very picky when it comes to user interface ... for now I
>>> just have to do the talk.
>>>
>> Well then, how about tossing us a sketch of how *you* think the GUI should
>> work?  We already got two (I suggested Windows Explorer, someone else
>> suggested .. another patch lib I forget now.)
> I would love to but for that I would need to get the application up
> and running, that is how my ideas are born.
>
> It have been a long time since I run JSL, probably around the time I
> committed my work to the project (was it 2005?) and the thoughts I had
> then are gone now. The only thing I remember now is that the
> application was a bit confusing for me before I understood how to use
> it and I think that part can be improved. For me, the best user
> interface is the one that does not require special knowledge about a
> field in order to get started.

On the subject of confusion, its not immediately obvious to a first time
user what the difference between a library and a scene is, so in the
long run we definitely need to either come up with a method of teaching
the first time user, or possibly change how it works.

frankie

Re: [Jsynthlib-devel] 10th anniversary

[Roger W. <ro...@us...>]

2011/9/23 William Zwicky <wrz...@po...>:
> On Thu, Sep 22, 2011 at 11:34 PM, Roger Westerlund <
> ro...@us...> wrote:
>
>>
>> Me myself is very picky when it comes to user interface ... for now I
>> just have to do the talk.
>>
>
> Well then, how about tossing us a sketch of how *you* think the GUI should
> work?  We already got two (I suggested Windows Explorer, someone else
> suggested .. another patch lib I forget now.)

I would love to but for that I would need to get the application up
and running, that is how my ideas are born.

It have been a long time since I run JSL, probably around the time I
committed my work to the project (was it 2005?) and the thoughts I had
then are gone now. The only thing I remember now is that the
application was a bit confusing for me before I understood how to use
it and I think that part can be improved. For me, the best user
interface is the one that does not require special knowledge about a
field in order to get started.

As I said, I will try to make time for looking into JSL again but I
can not promise anything.


/ Roger

Re: [Jsynthlib-devel] 10th anniversary

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

On Thu, Sep 22, 2011 at 11:34 PM, Roger Westerlund <
ro...@us...> wrote:

>
> Me myself is very picky when it comes to user interface ... for now I
> just have to do the talk.
>

Well then, how about tossing us a sketch of how *you* think the GUI should
work?  We already got two (I suggested Windows Explorer, someone else
suggested .. another patch lib I forget now.)

-Bill Zwicky

Re: [Jsynthlib-devel] 10th anniversary

[Roger W. <ro...@us...>]

2011/9/22 Joe Emenaker <jo...@em...>:
> On 9/21/2011 11:19 PM, Roger Westerlund wrote:
>> 2011/9/20 William Zwicky<wrz...@po...>:
>>> On Mon, Sep 19, 2011 at 11:28 PM, Roger Westerlund
>>> <ro...@us...>  wrote:
>>>> Or why don't we release a 1.0. That would be a bold move.
>>> 3.11 Enterprise Edition.  Comfortable now?
>
> Let's do it like Chrome, where we roll out a new major version number
> every couple of weeks! :)

Or like Forefox new versioning scheme.

Let's not. :-)

>> I believe we decide when we are stable. I have a hard time believing
>> that during the 10 years JSL has lived that we have not been in a
>> "stable" state at some point. And if we haven't, will we ever be
>> stable?
>
> Well, it *was* fairly stable, in times passed, but right now isn't one
> of those times.

I recall that the last time I tried to pick it up again from svn, it
did not work at all for me so I dropped it right away.

> Now, I think I get your point about version numbers and public
> perception. Whenever I'm browsing Sourceforge, and I see a version
> number like "0.10" or "0.28", I figure that the software is still only
> in its "proof of concept" stage, that most features are unimplemented,
> many things don't work right, and that it crashes frequently. In short,
> I figure that it will be more frustrating to try to use it that it would
> be to not use it at all.

That was exactly my point. Never underestimate public perception.

> JSL isn't quite *that* bad, but I do find the UI to be very
> counter-intuitive and I see lots of run-time exceptions thrown in the
> console. If "1.0" is earned just by merely doing something useful and
> doing it fairly reliably, then I'd put the current code at about 0.85 or
> 0.90.

I have seen some fairly crappy things at 1.0 in my times. They have
only been usable at version 3 or something. There could, of course, be
a point that you don't want to release anything that scares people
away and call it 1.0. That would hurt. However, I do not believe that
JSL, in the last incarnation I used it, was that scary. It had rooms
for improvements, of course, but nothing that could not be a 1.0.

> But this a rather moot point, to me. I really don't care how many other
> users we have. I want JSL to be useable to *me*, and I'll work to make
> it that way. So, I don't really care if we call it "0.01" forever.

If you are Joe Average, then I think it is good enough that is is
usable for you. :-)

Me myself is very picky when it comes to user interface (and code, not
going to share my views on the state of the code as I saw it the last
time) and I also believe I have a way to take a step outside of myself
in order to figure out how things would benefit the general user. I
should probably dust off the old D-10 (if it still works) and help out
in the work and I really wish I had the time for it. But for now I
just have to do the talk.

Regards,

Roger

Re: [Jsynthlib-devel] 10th anniversary

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

On Thu, Sep 22, 2011 at 9:27 AM, frankster <jsy...@te...>wrote:

> On the subject of bugs, as input to this discussion and I guess to help
> with the 0.21 release notes, I have been through the cvs list and made a
> list of user-visible fixes/changes since I subscribed to the jsl mailing
> lists at the end of august; no doubt there have been various other
> patches since the 0.20 release but the sf.net web interface is too much
> of a PITA to look back through 6 years of cvs list archives!
>

Awesome work, frankie.  Have things settled down?  I'd like to post 0.21
soon.

-Bill Zwicky

Re: [Jsynthlib-devel] 10th anniversary

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

On 09/22/11 16:02, Joe Emenaker wrote:
> On 9/21/2011 11:19 PM, Roger Westerlund wrote:
>> 2011/9/20 William Zwicky<wrz...@po...>:
>>> On Mon, Sep 19, 2011 at 11:28 PM, Roger Westerlund
>>> <ro...@us...>   wrote:
>>>> Or why don't we release a 1.0. That would be a bold move.
>>> 3.11 Enterprise Edition.  Comfortable now?
> Let's do it like Chrome, where we roll out a new major version number
> every couple of weeks! :)
>
>> I believe we decide when we are stable. I have a hard time believing
>> that during the 10 years JSL has lived that we have not been in a
>> "stable" state at some point. And if we haven't, will we ever be
>> stable?
> Well, it *was* fairly stable, in times passed, but right now isn't one
> of those times.
>
>> Big refactorings of the core is a major version leap. It would be a
>> good thing to have a "stable" release before the big refactoring since
>> big refactorings tends to need time for stabilizing (it's a fact). Why
>> not call that release 1.0 and we can let the big refactoring mature in
>> parallel to become 2.0?
> I agree that that's a possibility; that we could call the existing code
> "1.0" and then use "2.0" for the refactoring. It just didn't really turn
> out that way.
>
> Now, I think I get your point about version numbers and public
> perception. Whenever I'm browsing Sourceforge, and I see a version
> number like "0.10" or "0.28", I figure that the software is still only
> in its "proof of concept" stage, that most features are unimplemented,
> many things don't work right, and that it crashes frequently. In short,
> I figure that it will be more frustrating to try to use it that it would
> be to not use it at all.
>
> JSL isn't quite *that* bad, but I do find the UI to be very
> counter-intuitive and I see lots of run-time exceptions thrown in the
> console. If "1.0" is earned just by merely doing something useful and
> doing it fairly reliably, then I'd put the current code at about 0.85 or
> 0.90.
>
>
I do rather like the Roger's bold idea of calling it 1.0 to coincide 
with the 10 year anniversary. Having said that my feeling is that the 
software is beta level - a lot of it works fine but some bits are dodgy 
so perhaps not deserving of 1.0. Given the number of bugs I've easily 
found, I would expect that there are more lurking in there that I 
haven't run across yet.

On the subject of bugs, as input to this discussion and I guess to help 
with the 0.21 release notes, I have been through the cvs list and made a 
list of user-visible fixes/changes since I subscribed to the jsl mailing 
lists at the end of august; no doubt there have been various other 
patches since the 0.20 release but the sf.net web interface is too much 
of a PITA to look back through 6 years of cvs list archives!

Predominantly these are bug fixes and usability improvements.


bug/crash
-------------------------------------
   DX7 voice editor fix
   recover better from corrupt prefs
   correct unfussy regexes for various synths' autoscan
   table selection issue after removing duplicates from library
   fixed possible crash when number of midi devices decreases and do a 
better job at maintaining port settings


usability enhancement
-------------------------------------
   multiple midi interface fix
   images for TX81z waveforms
   keyboard shortcut for new patch
   excessive exit confirmations
   remember location of main window
   improved delete duplicates dialogue box(es)
   look and feel defaults to nimbus
   improved display/naming of midi devices


functionality enhancement
-------------------------------------
   DX100/TX81z envelope improvement
   librarian support for SY77
   M350 librarian/editor
   single driver for SY85
   improved matching up sysex with supporting drivers (scan more than 
just header)



frankie

Re: [Jsynthlib-devel] 10th anniversary

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

On 9/21/2011 11:19 PM, Roger Westerlund wrote:
> 2011/9/20 William Zwicky<wrz...@po...>:
>> On Mon, Sep 19, 2011 at 11:28 PM, Roger Westerlund
>> <ro...@us...>  wrote:
>>> Or why don't we release a 1.0. That would be a bold move.
>> 3.11 Enterprise Edition.  Comfortable now?

Let's do it like Chrome, where we roll out a new major version number 
every couple of weeks! :)

> I believe we decide when we are stable. I have a hard time believing
> that during the 10 years JSL has lived that we have not been in a
> "stable" state at some point. And if we haven't, will we ever be
> stable?

Well, it *was* fairly stable, in times passed, but right now isn't one 
of those times.

> Big refactorings of the core is a major version leap. It would be a
> good thing to have a "stable" release before the big refactoring since
> big refactorings tends to need time for stabilizing (it's a fact). Why
> not call that release 1.0 and we can let the big refactoring mature in
> parallel to become 2.0?

I agree that that's a possibility; that we could call the existing code 
"1.0" and then use "2.0" for the refactoring. It just didn't really turn 
out that way.

Now, I think I get your point about version numbers and public 
perception. Whenever I'm browsing Sourceforge, and I see a version 
number like "0.10" or "0.28", I figure that the software is still only 
in its "proof of concept" stage, that most features are unimplemented, 
many things don't work right, and that it crashes frequently. In short, 
I figure that it will be more frustrating to try to use it that it would 
be to not use it at all.

JSL isn't quite *that* bad, but I do find the UI to be very 
counter-intuitive and I see lots of run-time exceptions thrown in the 
console. If "1.0" is earned just by merely doing something useful and 
doing it fairly reliably, then I'd put the current code at about 0.85 or 
0.90.

But this a rather moot point, to me. I really don't care how many other 
users we have. I want JSL to be useable to *me*, and I'll work to make 
it that way. So, I don't really care if we call it "0.01" forever.

- Joe

Re: [Jsynthlib-devel] 10th anniversary

[Roger W. <ro...@us...>]

2011/9/20 William Zwicky <wrz...@po...>:
> On Mon, Sep 19, 2011 at 11:28 PM, Roger Westerlund
> <ro...@us...> wrote:
>>
>> Or why don't we release a 1.0. That would be a bold move.
>
> 3.11 Enterprise Edition.  Comfortable now?  Unfortunately, we have to charge
> for support.
>
>>
>> Why aren't we above 1.0 after 10 years, really? Is it still alpha
>> software?
>
> Noone's been working on it, so it's still alpha.  (Actually it's in the
> stage before alpha, also known as still in development.)
>
>>
>> That is probably one thing that some people objects to when they see
>> it, I know I feel more comfortable with a software which has passed
>> its 1.0 state.
>
> We can't go 1.0 til we're stable.  And we won't be stable as long as people
> keep refactoring the core.
>
> -Bill Zwicky
>
>

I believe we decide when we are stable. I have a hard time believing
that during the 10 years JSL has lived that we have not been in a
"stable" state at some point. And if we haven't, will we ever be
stable?

Big refactorings of the core is a major version leap. It would be a
good thing to have a "stable" release before the big refactoring since
big refactorings tends to need time for stabilizing (it's a fact). Why
not call that release 1.0 and we can let the big refactoring mature in
parallel to become 2.0?

We will need to refactor the core even after 2.0, hopefully in smaller
incremental steps, but there will probably come up new ideas regarding
the architecture of this application which will lead to another major
version leap when those are implemented.

That's just my two cents worth on this.

Regards,

Roger

Re: [Jsynthlib-devel] two ideas for jsynthlib

[Frankie F. <jsy...@te...>]

On 19/09/2011 21:56, Frankie Fisher wrote:
> On 19/09/2011 21:34, Maciej Łoziński wrote:
>> Hi
>>
>> I have two ideas that could improve jsynthlib.
>>
>> One, easier to do is implementing randomization of patches. 
> I thought there already was a randomise option, 

I've just had a look and it turns out there is something like this. Its
on the Library menu and its called Cross Breed. It generates a new patch
by taking each byte from a random patch in the library. Its not
completely random as its based on patches already in your library, but
it kind of ensures that any values it sets are legal (though can't
guarantee that the combinations of values are legal).

frankie

Re: [Jsynthlib-devel] no details available

[Frankie F. <jsy...@te...>]

On 20/09/2011 02:41, Joe Emenaker wrote:
> On 9/19/2011 6:11 PM, Frankie Fisher wrote:
>> Does anybody else see "no details available" in the input midi devices?
> Yes, and it bugs me.
>
>> Currently the device name that is displayed to the user is constructed
>> by concatenating DESCRIPTION and NAME, but I wonder if it should instead
>> be based on VENDOR and NAME which should stop this "No details available"?
> I vote: do it.
>
> - Joe
>
>

ha I tried that and it comes up wiht unknown vendor for them all!

so I guess only the device name is what we need

Re: [Jsynthlib-devel] [Jsynthlib-cvs] SF.net SVN: jsynthlib:[1158] trunk/JSynthLib/core

[Frankie F. <jsy...@te...>]

On 20/09/2011 20:42, William Zwicky wrote:
> On Tue, Sep 20, 2011 at 10:45 AM, Frankie Fisher <
> jsy...@te...> wrote:
>
>> .. constant re-querying is a pain in the arse ..
>>
> How about this: jsl only saves a list of which ports were DISabled, by
> name.  (There's a unique name string for each port, isn't there?)  I think
> this supports the use cases mentioned above -- jsl picks up all ports with
> about spamming user, but hides the ports the user doesn't want jsl to
> manage.
This would probably work as long as we also have some method of
automatically figuring out which port a device is on or if its not
connected. would we need to do a device scan (06 01) each time at
startup to work out which port a device is on? I know not all devices
support this though.
>
> I also believe that jsl should be port-agnostic -- if a synth moves to
> another port, jsl should assume it's the same synth and not bother the
> user.  But there's another problem (maybe) -- what if the user has two
> copies of the same synth?  Is that even a problem?
Can we assume that duplicate synths will always have a different device
id? or are there some devices where this isn't the case? maybe synths
that dont support device ids?

frankie

Re: [Jsynthlib-devel] [Jsynthlib-cvs] SF.net SVN: jsynthlib:[1158] trunk/JSynthLib/core

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

On 9/20/2011 12:42 PM, William Zwicky wrote:
> How about this: jsl only saves a list of which ports were DISabled, by 
> name.

That's exactly what I was going to suggest.

> I also believe that jsl should be port-agnostic -- if a synth moves to 
> another port, jsl should assume it's the same synth and not bother the 
> user. But there's another problem (maybe) -- what if the user has two 
> copies of the same synth? Is that even a problem?

It could be. What if I want different banks on the different synths?

What I was thinking is that, if some sysex comes in on a port, and JSL 
can't find a driver assigned to that port which "claims" that sysex for 
itself, but there *is* a driver for that sysex assigned to a *different* 
port, then JSL could ask "Is this one of your current BFD-100's, or is 
this a new one?". That kinda deal.

> On a related note, I've never liked the GUI.

It's horrific.

> When I first started using jsl, I expected something more like Windows 
> Explorer 2-pane view, which shows folders on the left and files on the 
> right. In this case, the left pane would show ports, and under each 
> port would be the synths on that port. Ports blocked by the user would 
> still appear, but greyed out.

Actually, I was thinking of either something like Midiquest 
(http://www.soundquest.org/images/MQ10/MQ10.1280.png) where you have 
images of the synths, or something like a "desktop", where you've got 
icons of all of your synths which you can drag around the way you want 
to look like your studio arrangement.

Either way, I think images of the synths would be a nice improvement.

- Joe

Re: [Jsynthlib-devel] [Jsynthlib-cvs] SF.net SVN: jsynthlib:[1158] trunk/JSynthLib/core

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

On Tue, Sep 20, 2011 at 10:45 AM, Frankie Fisher <
jsy...@te...> wrote:

>
> .. constant re-querying is a pain in the arse ..
>

How about this: jsl only saves a list of which ports were DISabled, by
name.  (There's a unique name string for each port, isn't there?)  I think
this supports the use cases mentioned above -- jsl picks up all ports with
about spamming user, but hides the ports the user doesn't want jsl to
manage.

I also believe that jsl should be port-agnostic -- if a synth moves to
another port, jsl should assume it's the same synth and not bother the
user.  But there's another problem (maybe) -- what if the user has two
copies of the same synth?  Is that even a problem?

On a related note, I've never liked the GUI.  When I first started using
jsl, I expected something more like Windows Explorer 2-pane view, which
shows folders on the left and files on the right.  In this case, the left
pane would show ports, and under each port would be the synths on that
port.  Ports blocked by the user would still appear, but greyed out.

-Bill Zwicky

Re: [Jsynthlib-devel] [Jsynthlib-cvs] SF.net SVN: jsynthlib:[1158] trunk/JSynthLib/core

[Frankie F. <jsy...@te...>]

On 20/09/2011 15:13, Joe Emenaker wrote:
>
> I think the toughest part is deciding how JSL should respond when *some* 
> of the selected interfaces go missing. Suppose I have two USB MIDI 
> interfaces, and I have some drivers using ports on each one. Then, I 
> remove one of the MIDI interfaces and then run JSL again. Should JSL 
> re-query the user about:
>   1 - Which ports to listen on?
>   2 - The port assignments for every driver which had its port go missing?
> or do we want to just have JSL fail-over to a default port?
>
> If we just give the user a default, what do we do if that interface 
> shows back up again, later?
Yep this is a problem that came up when I fixed the issue with midi
ports last night. If you have a synth connected to USB interface X which
is disconnected, before it would either end up on a random interface or
crash, whereas now it will fail to load that interface and instead
connect to whichever interface happens to be in position 0. I think this
then gets saved at some point so if you start it up again but this time
the interface is there, you will remain on whichever interface was at 0
the previous time.

I think rather than fall back to a default port the better outcome would
be that it retains the interface the user set it at and the interface
could be marked as unavailable in any lists that are displayed. 
Possibly re-query the user or maybe just warn them that the port is not
available. It would depend if its a common use case to disconnect and
reconnect ports, and if constant re-querying is a pain in the arse or not!

frankie

Re: [Jsynthlib-devel] [Jsynthlib-cvs] SF.net SVN: jsynthlib:[1158] trunk/JSynthLib/core

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

On 9/20/2011 12:40 AM, Frankie Fisher wrote:
> off the top of my head, the only time i can think of where it would be 
> an advantage not to be using all ports is in the "autoscan" 
> functionality because it takes a while to scan each port.

Keep in mind that I'm talking about the MIDI layer *listening* on all 
input ports. What this means is:
1 - Drivers still need to decide which port to send *out* on, and
2 - *Drivers* actually (currently) need to decide which port to listen on.

Basically, the initial thing that we'll be able to do when the 
underlying MIDI layer listens on everything is to be able to plug a 
synth into any MIDI input port, send a sysex dump, and JSL will notice 
it and be able to bring up a pop-up asking the user what to do about it 
(save it as a Generic patch, search for a driver for it, assign an 
existing driver to that new input port, discard it, etc.)

> Having said that there's no reason why we couldn't scan on all ports 
> in parallel. Maybe there would be some situation where another app 
> could be sending/receiving sysex so maybe we would want to exclude 
> some ports. Maybe we should have an interface like midi-ox where we 
> can multiple select all the ports we want to use

That's what I was thinking. Initially, it'll be easier to just listen on 
everything and figure out what nifty features that enables for us. Then, 
we can put in the config stuff where the user can select individual ports.

I think the toughest part is deciding how JSL should respond when *some* 
of the selected interfaces go missing. Suppose I have two USB MIDI 
interfaces, and I have some drivers using ports on each one. Then, I 
remove one of the MIDI interfaces and then run JSL again. Should JSL 
re-query the user about:
  1 - Which ports to listen on?
  2 - The port assignments for every driver which had its port go missing?
or do we want to just have JSL fail-over to a default port?

If we just give the user a default, what do we do if that interface 
shows back up again, later?

- Joe

Re: [Jsynthlib-devel] [Jsynthlib-cvs] SF.net SVN: jsynthlib:[1158] trunk/JSynthLib/core

[Frankie F. <jsy...@te...>]

On 20/09/2011 02:40, Joe Emenaker wrote:
> While you're in that zone, consider this. In the refactor, the new MIDI 
> code is going to be able to listen on *all* available input ports at 
> once, so the current MIDI configuration panel (where you select a single 
> input and single output port) is going to need to be altered a bit.
>
> I don't know if we want to let the user select which portS they want JSL 
> to listen on, or do we want JSL to just listen to everything available 
> all the time?
>
>
off the top of my head, the only time i can think of where it would be
an advantage not to be using all ports is in the "autoscan"
functionality because it takes a while to scan each port. Having said
that there's no reason why we couldn't scan on all ports in parallel.

Maybe there would be some situation where another app could be
sending/receiving sysex so maybe we would want to exclude some ports.
Maybe we should have an interface like midi-ox where we can multiple
select all the ports we want to use

franie

Re: [Jsynthlib-devel] 10th anniversary

[Roger W. <ro...@us...>]

2011/9/19 frankster <jsy...@te...>:
> On 09/19/11 18:31, Joe Emenaker wrote:
>> On 9/16/2011 7:24 AM, frankster wrote:
>>> Just noticed that the sf.net page was registered in december 2001, which
>>> means that JSL is nearly 10 years old!
>> Should we release a special "Collector's Edition"? It could come with a
>> certificate of authenticity signed by all of us. :-)
>>
>> Or, maybe... we could just do a release at all.
>>
> haha well why don't we call 0.21 the 10 year anniversary release? maybe
> get a mention on some website because of it. I guess 0.21 will be out
> before December but whatever!

Or why don't we release a 1.0. That would be a bold move.

Why aren't we above 1.0 after 10 years, really? Is it still alpha software?

That is probably one thing that some people objects to when they see
it, I know I feel more comfortable with a software which has passed
its 1.0 state.

Regards,

Roger

Re: [Jsynthlib-devel] two ideas for jsynthlib

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

On 09/19/2011 03:56 PM, Frankie Fisher wrote:
>> Second idea is more complicated and to be honest I have no idea how to
>> >  realize it:-D  But It would be great to be able to translate patches
>> >  between synths, at least to some extent.
> You're right, this is ridiculously complicated!

Actually, come think of it, it is not THAT complicated. At least for 
real algorithmic synths, i mean those that do not use samples.

What lands itself for such task would be some sort of standard 
capability language for synth drivers. Something with objects being 
different facilities involved in sound creation (generators, filters), 
and their properties.

Then translation would be just mapping of patch components in converted 
voice onto facilities available in target synth.

That in general leads to some sort of scripting support in JSL, which 
probably would be similar to other existing sound scripting languages 
(c-sound?). Not that I am familiar with any, but learning c-sound is 
long on my list of things to do.

-- 
Vladimir

Re: [Jsynthlib-devel] no details available

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

On 9/19/2011 6:11 PM, Frankie Fisher wrote:
> Does anybody else see "no details available" in the input midi devices?

Yes, and it bugs me.

> Currently the device name that is displayed to the user is constructed
> by concatenating DESCRIPTION and NAME, but I wonder if it should instead
> be based on VENDOR and NAME which should stop this "No details available"?

I vote: do it.

- Joe

Re: [Jsynthlib-devel] [Jsynthlib-cvs] SF.net SVN: jsynthlib:[1158] trunk/JSynthLib/core

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

On 9/19/2011 6:08 PM, fra...@us... wrote:
> fixed crash which can occur at startup when less midi devices are installed than when prefs were saved.
>
> The problem was that the midi device is stored in the prefs as an integer. When the prefs are loaded, the device number is loaded and no checks are performed causing an array out of bounds exception if you now have less devices than the device number you had previously configured.
>
> This also caused a problem that the configured devices could change if you plugged in or unplugged a usb device that wasn't even used by JSL, as the correct device would now be in a different position in the array.  Given that USB midi devices are probably a lot more common now than 10 years ago, its probably quite common now that available devices might vary from session to session.
>
> I have changed it so that the midi device is stored as a string (using vladimir's de-duplicated name). When JSL is re-started, as long as the same device name exists, it will be configured correctly regardless of where the device appears in the array.

Actually, I already was planning on doing that in the refactor, so you 
probably saved me some work. Saving the interfaces by name will be much 
more reliable.

While you're in that zone, consider this. In the refactor, the new MIDI 
code is going to be able to listen on *all* available input ports at 
once, so the current MIDI configuration panel (where you select a single 
input and single output port) is going to need to be altered a bit.

I don't know if we want to let the user select which portS they want JSL 
to listen on, or do we want JSL to just listen to everything available 
all the time?

- Joe

[Jsynthlib-devel] no details available

[Frankie F. <jsy...@te...>]

Does anybody else see "no details available" in the input midi devices?



Currently the device name that is displayed to the user is constructed
by concatenating DESCRIPTION and NAME, but I wonder if it should instead
be based on VENDOR and NAME which should stop this "No details available"?

frankie

Re: [Jsynthlib-devel] two ideas for jsynthlib

[Frankie F. <jsy...@te...>]

On 19/09/2011 21:34, Maciej Łoziński wrote:
> Hi
>
> I have two ideas that could improve jsynthlib.
>
> One, easier to do is implementing randomization of patches. It would be 
> not much work, as we already have all parameter ranges for patches where 
> there are PatchEditors present. There could be two options - randomize 
> all parameters, or only parameters designated by programmer (because 
> some parameters should not be randomized). I think it would be great 
> editing patches starting from some weird sounds and polish them to be 
> "listenable" ;-) I have such option in my Waldotf MicroQ and I think it 
> would be great to have this on any of my synths :-) What do you think? 
> Could it be implemented as a part of ongoing code refactoring?

I thought there already was a randomise option, but regardless something
like this is totally on my list of things to do. These are things that I
think could be interesting:
* totally random parameters
* starting with an existing patch, randomise only a few parameters, or
change their values slightly from their existing settings
* merge two patches - e.g. take average of all parameters, or by take
parameters randomly from one of the initial patches

This is something I might look at some time after I've done my Proteus
2000 family driver.

>
> Second idea is more complicated and to be honest I have no idea how to 
> realize it :-D But It would be great to be able to translate patches 
> between synths, at least to some extent.

You're right, this is ridiculously complicated!

frankie

Re: [Jsynthlib-devel] Tip-of-the-day system

[Maciej Ł. <loz...@o2...>]

Most (if not all) Swing components render html:

http://download.oracle.com/javase/tutorial/uiswing/components/html.html

cheers
Maciek

W dniu 17.09.2011 20:18, frankster pisze:
>
> I suppose that a separate file would be best as it would mean that
> programming skills (however minimal) wouldn't be required to add tips.
>
> A quick google search says that there is a control called JEditorPane
> which can display html.
>
> frankie
>