Thread: [Jsynthlib-devel] 10th anniversary

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Just noticed that the sf.net page was registered in december 2001, which 
means that JSL is nearly 10 years old!

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.

- Joe

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!

frankie

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

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

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

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

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

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

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

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

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

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

On 9/23/2011 6:21 AM, frankster wrote:
> 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.

Ah! I thought scenes were something else. Now that I look at the code, 
it is becoming clear to me (and it's also becoming clear that it's coded 
improperly... not just in how the GUI's for them look, but in how 
they're coded on the back-end).

Here are my general thoughts on this:
  - The "Library" frame is a spreadsheet with the patches and comments, 
without any location info. The "Scene" frame is a spreadsheet with the 
patches and the bank/patch location on the target synth. But the 
spreadsheets look too similar. I'd prefer that the "Scene" spreadsheet 
have its rows/columns match the banks/patches on the synth, so we can 
drag/drop them around to arrange the patches however we want.
  - Both the Library and Scene frames allow us to have patches for 
different synths in a single window. This strikes me as more confusing 
than helpful. I'd prefer to have each Library be limited to just one synth.
  - If we were to have Library frames limited to one synth, then I think 
a Library frame should have *all* of the patches for that synth. So, the 
DX7 Library frame would have *all* of the patches for a DX7 that JSL 
knows of, regardless of where they came from. Because of *that*, you 
could make the argument that there's no need to ever have more than one 
Library frame for a synth open at one time. You could have multiple 
*Scenes* open, and you could be dragging patches from the one Library 
window into several different Scenes... but you wouldn't need to have 
multiple Library frames for a single synth.
  - The more I think about it, I think of JSL's relationship to synths 
as similar to iTunes' relationship to iPhone/iPod, in that iTunes holds 
all of your known media, and then some subset of that is synced to your 
iPhone or iPod. So, I'm trying to work out some kind of "sync" paradigm 
for JSL. For starters, since the Library is holding the computer-side 
representation of the patches, it's not limited by the synth's name 
limitations, so I think JSL should let us give long names to the patches 
in the library. When they're placed into a Scene, then their name either 
gets truncated to what the synth's limitation is, or we could maintain a 
LongName and a ShortName... who knows?
  - Going further with the "sync" notion, we could have JSL deal, in a 
smart way, with changed patches it sees from the synth. For example, 
suppose I've got a patch called "Swoopy" in my library, and I send it to 
my synth. Then, I modify the patch on the synth (during a performance, 
say). And then, afterward, I sync a Scene with my synth and JSL would 
notice that there's a patch called "Swoopy" on the synth which doesn't 
match the "Swoopy" in the Library. I could be given a choice of: 1) 
Overwrite the one in the Library, 2) Overwrite the one on the synth, or 
3) Make a new "Swoopy-2" in the library to hold the new one found on the 
synth.

Anyway, those are just some of the ideas I had floating around in my head...

- Joe

On 23/09/2011 17:04, Joe Emenaker wrote:
> On 9/23/2011 6:21 AM, frankster wrote:
>> 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.
> Ah! I thought scenes were something else. Now that I look at the code, 
> it is becoming clear to me (and it's also becoming clear that it's coded 
> improperly... not just in how the GUI's for them look, but in how 
> they're coded on the back-end).
>
> Here are my general thoughts on this:
>   - The "Library" frame is a spreadsheet with the patches and comments, 
> without any location info. The "Scene" frame is a spreadsheet with the 
> patches and the bank/patch location on the target synth. But the 
> spreadsheets look too similar. I'd prefer that the "Scene" spreadsheet 
> have its rows/columns match the banks/patches on the synth, so we can 
> drag/drop them around to arrange the patches however we want.

I think there is scope for a synth-level scene and then something to
configure ALL synths in one go. Basically a group of scenes (performance?).

>   - Both the Library and Scene frames allow us to have patches for 
> different synths in a single window. This strikes me as more confusing 
> than helpful. I'd prefer to have each Library be limited to just one synth.

Yep I agree that we should restrict libraries to one synth. as I comment
above, I think we need a mechanism to control the setup of one synth,
and a mechanism to control the setup of all synths. This could be
achieved either by allowing scenes to hold setups for several synths, or
have a new concept of a grouping of scenes. Probably the latter I think,
so that would give us 3 concepts. Library, SynthSetup, Performance.

>   - If we were to have Library frames limited to one synth, then I think 
> a Library frame should have *all* of the patches for that synth. So, the 
> DX7 Library frame would have *all* of the patches for a DX7 that JSL 
> knows of, regardless of where they came from. Because of *that*, you 
> could make the argument that there's no need to ever have more than one 
> Library frame for a synth open at one time. You could have multiple 
> *Scenes* open, and you could be dragging patches from the one Library 
> window into several different Scenes... but you wouldn't need to have 
> multiple Library frames for a single synth.

Disagree. Firstly libraries with thousands of patches in might be
unwieldy. Secondly, it could make it harder to organise sounds. For
example, last night I was separating some TX81z sounds so that I could
use the "cross breed" functionality on them. I wanted to generate some
bass synth sounds and some drum-like sounds. Because of the way cross
breed works (randomly off any patch in the library), I found it useful
to have a group of drum-like patches in one library, and a group of bas
synthy sounds in another library. This way the cross-breed wouldn't
attempt to use the shitty "choir" patches in the main library that
haven't really stood the test of time, and when I bred drummy sounds
with other drummy sounds, the output was more likely to be a drummy sound.

That's not to say that we can't have a *view* of all patches for a
device. Just as itunes has albums, but might display the individual
tracks in a big list.

>   - The more I think about it, I think of JSL's relationship to synths 
> as similar to iTunes' relationship to iPhone/iPod, in that iTunes holds 
> all of your known media, and then some subset of that is synced to your 
> iPhone or iPod. So, I'm trying to work out some kind of "sync" paradigm 
I agree with this abstraction/workflow, I think it would be useful and
intuitive.

> for JSL. For starters, since the Library is holding the computer-side 
> representation of the patches, it's not limited by the synth's name 
> limitations, so I think JSL should let us give long names to the patches 
> in the library. When they're placed into a Scene, then their name either 
> gets truncated to what the synth's limitation is, or we could maintain a 
> LongName and a ShortName... who knows?
There's no reason we can't add all sorts of tags to patches, such as
author, comments, notes, ratings etc.

>   - Going further with the "sync" notion, we could have JSL deal, in a 
> smart way, with changed patches it sees from the synth. For example, 
> suppose I've got a patch called "Swoopy" in my library, and I send it to 
> my synth. Then, I modify the patch on the synth (during a performance, 
> say). And then, afterward, I sync a Scene with my synth and JSL would 
> notice that there's a patch called "Swoopy" on the synth which doesn't 
> match the "Swoopy" in the Library. I could be given a choice of: 1) 
> Overwrite the one in the Library, 2) Overwrite the one on the synth, or 
> 3) Make a new "Swoopy-2" in the library to hold the new one found on the 
> synth.

yep - although in my experience scanning synths entire preset libraries
can take a long time, but that doesn't mean it wouldn't be a useful
feature albeit with some caveats.

frankie

On Fri, Sep 23, 2011 at 9:04 AM, Joe Emenaker <jo...@em...> wrote:

>
> Here are my general thoughts on this:
>  - The "Library" frame is a spreadsheet with the patches and comments,
> without any location info. The "Scene" frame is a spreadsheet with the
> patches and the bank/patch location on the target synth. But the
> spreadsheets look too similar. I'd prefer that the "Scene" spreadsheet
> have its rows/columns match the banks/patches on the synth, so we can
> drag/drop them around to arrange the patches however we want.
>

That would be cool.

>  - Both the Library and Scene frames allow us to have patches for
> different synths in a single window. This strikes me as more confusing
> than helpful. I'd prefer to have each Library be limited to just one synth.
>

That seems reasonable.  We might preserve secret support for multi-synth
libraries, so JSL can open old files.

>  - If we were to have Library frames limited to one synth, then I think
> a Library frame should have *all* of the patches for that synth. So, the
> DX7 Library frame would have *all* of the patches for a DX7 that JSL
> knows of, regardless of where they came from.

It's up to the user to decide if they want one giant library, or lots of
little ones.  Merging them would make it confusing.

>   - The more I think about it, I think of JSL's relationship to synths
> as similar to iTunes' relationship to iPhone/iPod, in that iTunes holds
> all of your known media, and then some subset of that is synced to your
> iPhone or iPod. So, I'm trying to work out some kind of "sync" paradigm
> for JSL. For starters, since the Library is holding the computer-side
> representation of the patches, it's not limited by the synth's name
> limitations, so I think JSL should let us give long names to the patches
> in the library. When they're placed into a Scene, then their name either
> gets truncated to what the synth's limitation is, or we could maintain a
> LongName and a ShortName... who knows?
>

Perhaps "label" and "description".  I agree, I wasn't happy when I
discovered JSL copied my synth's limitations.

>  - Going further with the "sync" notion, we could have JSL deal, in a
> smart way, with changed patches it sees from the synth. For example,
> suppose I've got a patch called "Swoopy" in my library, and I send it to
> my synth. Then, I modify the patch on the synth (during a performance,
> say). And then, afterward, I sync a Scene with my synth and JSL would
> notice that there's a patch called "Swoopy" on the synth which doesn't
> match the "Swoopy" in the Library. I could be given a choice of: 1)
> Overwrite the one in the Library, 2) Overwrite the one on the synth, or
> 3) Make a new "Swoopy-2" in the library to hold the new one found on the
> synth.
>

I think I have to disagree .. Scenes are meant for live performance.  The
time required to detect this would probably be excessive, but more
importantly we can't bug the user with dialogs in this situation.  We need
to transmit the patches as quickly and cleanly as possible.

-Bill Zwicky

On 9/23/2011 11:50 AM, William Zwicky wrote:
> On Fri, Sep 23, 2011 at 9:04 AM, Joe Emenaker<jo...@em...>  wrote:
>
>>   - Going further with the "sync" notion, we could have JSL deal, in a
>> smart way, with changed patches it sees from the synth. For example,
>> suppose I've got a patch called "Swoopy" in my library, and I send it to
>> my synth. Then, I modify the patch on the synth (during a performance,
>> say). And then, afterward, I sync a Scene with my synth and JSL would
>> notice that there's a patch called "Swoopy" on the synth which doesn't
>> match the "Swoopy" in the Library. I could be given a choice of: 1)
>> Overwrite the one in the Library, 2) Overwrite the one on the synth, or
>> 3) Make a new "Swoopy-2" in the library to hold the new one found on the
>> synth.
>>
> I think I have to disagree .. Scenes are meant for live performance.  The
> time required to detect this would probably be excessive, but more
> importantly we can't bug the user with dialogs in this situation.  We need
> to transmit the patches as quickly and cleanly as possible.

Well, I didn't say that we should get rid of the "send" command. There'd 
be the option to send a Scene to a synth and over-write it completely. 
But my reason for wanting to add a "sync" is that there have been times 
where I made a patch at home, with a patch editor and sent it to my 
device. Then, in performance or rehearsal, it turned out that it needed 
tweaking, so I tweaked it. Let's say that happened with a half-dozen 
patches. Then, I got it home and didn't remember which patches I had 
tweaked. Now, I guess I could have just downloaded the whole Scene from 
the device again, but then what? Do I overwrite my previous Scene in JSL 
and then lose any changes I made to the Scene since I last dumped it to 
the device? Or, I could download it to a *new* Scene and then I'll have 
a bunch of duplicate-named patches in two different Scenes and the 
"latest" versions of each will be distributed among them.

So, I still maintain that, if there isn't a time constraint, then 
there's some benefit to JSL being able to detect that certain patches 
are just "modified" versions of previous ones.

- Joe

I'd also like to remove synths from the Preferences page.  You should pick
synth(s) when creating libraries and scenes.

-Bill Zwicky

On 23/09/2011 19:56, William Zwicky wrote:
> I'd also like to remove synths from the Preferences page.  You should pick
> synth(s) when creating libraries and scenes.
>
how does this fit in with the auto-scan process - do you anticipate
doing an autoscan every time you create a library? This doesn't seem
desirable to me cos autoscan is a bit slow, even if we get autoscan
working in parallel across all ports. And not all synths support
autoscan anyway, so you do anticipate displaying the list of all
supported synths and choosing one?

At the moment I find it a bit of a pain when creating a new patch that I
always have to choose the synth then choose the sub-type of patch e.g.
bank or single. If patches already exist within a library and the
library is locked to one synth, then this should reduce that point of
friction as we already know what kind of patch we would be creating
which will be a nice benefit of locking libraries to synths. And while
we might be creating loads of patches for a synth, we shouldn't be
creating new libraries THAT often. So I could tolerate friction when
creating a library more than the current friction when creating a
patch.  Still, if you have to navigate a big list of synths every time
you create a library it might get annoying.

Maybe there could be an autodetect scheme whereby you create a new
library, then you have the option of either playing a note or moving a
controller on the synth you want to use it for, then JSL detects the
port and does an autoscan and hopefully only gets one response. However
not all synths have keyboards or controller knobs so this would be
flawed I guess...

just some thoughts,
frankie

On 9/23/2011 4:58 PM, Frankie Fisher wrote:
> On 23/09/2011 19:56, William Zwicky wrote:
>> I'd also like to remove synths from the Preferences page.  You should pick
>> synth(s) when creating libraries and scenes.
>>
> how does this fit in with the auto-scan process - do you anticipate
> doing an autoscan every time you create a library? This doesn't seem
> desirable to me cos autoscan is a bit slow, even if we get autoscan
> working in parallel across all ports.

I think he actually meant that the user should explicitly choose what 
driver he/she wants to use for that library. There wouldn't be an 
autoscan involved.

I think it would be an improvement. The only issue I see is that, as the 
list of synthdrivers expands, choosing your synth every time you create 
a library could get cumbersome.

What I'd still prefer is something like MidiQuest, where you'd choose 
the synths in your studio, somehow, and they'd be listed along the left 
side of the window. Any time you want a new library, you just 
right-click on that synth to bring up a pop-up menu and you'd select 
"New Library".

- Joe

I've enclosed a sketch of a new GUI, based on my own fevered imagination as
well as your suggestions.  I'm not certain I'll ever do any of this (sorry)
but I wanted to write down something more concrete than "the GUI sucks".  If
someone ever works on the GUI, this might make a good starting point.  The
Studio window in particular should be possible with minimal modifications to
the core.

-Bill Zwicky

On 9/24/2011 2:25 PM, William Zwicky wrote:
> I've enclosed a sketch of a new GUI,

I haven't had time to look it over in detail, but I like the idea of a 
"Studio" window. In fact, my vision for the GUI is that the Studio 
window would actually be a pane/frame on the desktop which is always there.

One question though: What are your thoughts surrounding "Projects" being 
the master context (ie, you can only have one open at a time, and it's 
the thing that holds everything else)? My initial thought was that a 
Studio would be better as the master context. So, you'd "Open a studio" 
and that would have your synths for that studio layout and it would have 
all of your patches for that studio layout.

It seems reasonable to me that you could have different projects you're 
doing with a single studio setup, so I'm not sure "Project" should be a 
broader context than Studio.

- Joe

On 09/22/11 22:41, William Zwicky wrote:
> 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.
>
There is definitely one bug I want to fix before 0.21 - its the issue 
where the patch editors ask you to save changes even if you haven't 
modified anything.

I would also like an up-to-date synths list available to coincide with 
the time of the release. I'll see if this can be hosted on the project 
sf.net web page and if I have access to do this. On the subject of the 
auto-generated synths list, if i remember correctly there were two 
outstanding issues with that. 1) the "comment" field. In the long run 
this might be solved by a config file if we have modular drivers, but 
for now I think this should be solved by adding a comment field into 
every driver in the same way as the info text. the comment field can be 
called "support info" or something, and its entire purpose is to 
document the level of support of a driver for inclusion into the 
synths.html.
The other issue is that I can't remember if your auto-generation code 
could work out if we had patch /bank library/editor support or not. If 
not, maybe a filename string match could be good enough?

Also I noticed this guy Thorsten who has been updating jsynthlib a bit 
over here: http://midibox.org/forums/topic/14981-jsynthlib-update/
I'd like to look at getting his work into 0.21 so I'm going to try and 
contact him.

frankie

Hi,

> Also I noticed this guy Thorsten who has been updating jsynthlib a bit
> over here: http://midibox.org/forums/topic/14981-jsynthlib-update/
> I'd like to look at getting his work into 0.21 so I'm going to try and
> contact him.

it could be that he didn't change anything and simply released a new
JAR with the code from the SVN repository.

Cheers
Joachim

On 23/09/2011 18:57, Joachim wrote:
> Hi,
>
>> Also I noticed this guy Thorsten who has been updating jsynthlib a bit
>> over here: http://midibox.org/forums/topic/14981-jsynthlib-update/
>> I'd like to look at getting his work into 0.21 so I'm going to try and
>> contact him.
> it could be that he didn't change anything and simply released a new
> JAR with the code from the SVN repository.
>
>
Yep he replied to me, and everything is in the repository - I think he
did exactly what you said :)

frankie

Thread: [Jsynthlib-devel] 10th anniversary

jsynthlib-devel