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

Re: [Jsynthlib-devel] 10th anniversary

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

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

Re: [Jsynthlib-devel] 10th anniversary

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

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

[Jsynthlib-devel] sysex sending delays

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

I have just put in a patch that slightly changes the way delays work in
sysex. The old behaviour is that no delay is added when sending a sysex
from a driver, unless there is a max buffer size set (either in the
driver or in global prefs) which causes the message to be split up into
fragments as it is sent. If this happens, a delay configured either in
the device or in the global prefs is inserted (in the ui thread!) after
each fragment of the message has been sent.

I noticed that if a driver sent several small sysex messages then no
delay would get inserted between them. So I have modified the sending
code so that it would always apply the sysex delay whether or not it
split the message.

I think this is the right thing to do as it makes the global sysex delay
preference behave more as you would expect, but I could probably
persuaded that drivers should put in delays themselves if they need
them. in which case this change could be backed out (and I would put the
delays directly into the TX81z driver which motivated this change).

frankie

Re: [Jsynthlib-devel] 10th anniversary

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

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

Re: [Jsynthlib-devel] 10th anniversary

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

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

Re: [Jsynthlib-devel] 10th anniversary

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

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

Re: [Jsynthlib-devel] 10th anniversary

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

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

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

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

On Fri, Sep 23, 2011 at 11:19 AM, Joachim <li...@sd...> wrote:

>
> most applications have a name that doesn't imply it's use but are catchy,
> right?
> Gimp, Apache, Tomcat, JBoss, Inkscape, Firefox, Chrome, Opera, Gnumeric,
> ...
>

Microsoft Word, VideoLAN Client, MySQL, VirtualBox, 7-Zip ...

:^P

-Bill Zwicky

Re: [Jsynthlib-devel] 10th anniversary

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

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

-Bill Zwicky

Re: [Jsynthlib-devel] 10th anniversary

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

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

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

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

Hi,

 > I'm thinking that we might want some combination of two words: what it
 > does stuff *with*, and what it *does* with them.

most applications have a name that doesn't imply it's use but are catchy, right?
Gimp, Apache, Tomcat, JBoss, Inkscape, Firefox, Chrome, Opera, Gnumeric, ...

I think the catchyness is more important than implying it's use.
SynthJ, JSysexManager or JSynthManager are not really an improvement.

 >> JSynthLib sounds like library, not application. For this reason I passed
 >> by it in searches when looking for synth applications.

That's a point.

If we start a name context I'll throw in:
- Jones (*J*ava *O*pen source *N*ice *E*ditor and librarian for *S*ysex)
- Jamidiquai
- MIDIthang
- No SysEx till marriage
;)

May the winner get eternal praise.

Cheers
Joachim


Am 23.09.2011 17:29, schrieb Joe Emenaker:
> On 9/23/2011 8:17 AM, Vladimir Avdonin wrote:
>> Hey, maybe this would be good moment to maybe contemplate on maybe
>> uhmm... name change?
>
> Actually, when we're on the verge of actually getting control of the
> domain... that would be the *last* time to contemplate it. :) The time
> to contemplate it is when Brian has the domain paid up for years and
> doesn't get back to us... or when a domain-squatter gets a hold of it
> and wants a lot of money.
>
> But, now that you've mentioned it...
>
>> JSynthLib sounds like library, not application. For this reason I passed
>> by it in searches when looking for synth applications.
>>
>> How about SynthJ for the first contest entry?
>
> I like that it's short, but it's still a little cryptic.
>
> I'm thinking that we might want some combination of two words: what it
> does stuff *with*, and what it *does* with them. Off the top of my head,
> only two words for each category come to mind:
> (Sysex|Synth)(Manager|Librarian)
>
> And then an optional "J" at the front. So, we could have something like
> "JSysexManager" (and, yes, I realize that one of the pairings,
> "JSynthLibrarian", is almost identical to what we have now).
>
> Anyway, just a thought.
>
> - Joe
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2dcopy2
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>

Re: [Jsynthlib-devel] 10th anniversary

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

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

Re: [Jsynthlib-devel] 10th anniversary

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

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

Re: [Jsynthlib-devel] 10th anniversary

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

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

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

[denis q. <dqu...@fr...>]

SynthyPatcher

Sounds great in french ;)

--
Denis

How about SynthJ for the first contest entry?

> I like that it's short, but it's still a little cryptic.
>
> I'm thinking that we might want some combination of two words: what it
> does stuff *with*, and what it *does* with them. Off the top of my head,
> only two words for each category come to mind:
> (Sysex|Synth)(Manager|Librarian)
>
> And then an optional "J" at the front. So, we could have something like
> "JSysexManager" (and, yes, I realize that one of the pairings,
> "JSynthLibrarian", is almost identical to what we have now).
>
> Anyway, just a thought.
>
> - Joe
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2dcopy2
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>

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

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

On 09/23/11 16:29, Joe Emenaker wrote:
> On 9/23/2011 8:17 AM, Vladimir Avdonin wrote:
>> JSynthLib sounds like library, not application. For this reason I passed
>> by it in searches when looking for synth applications.
>>
>> How about SynthJ for the first contest entry?
> I like that it's short, but it's still a little cryptic.
>
> I'm thinking that we might want some combination of two words: what it
> does stuff *with*, and what it *does* with them. Off the top of my head,
> only two words for each category come to mind:
> (Sysex|Synth)(Manager|Librarian)
>
> And then an optional "J" at the front. So, we could have something like
> "JSysexManager" (and, yes, I realize that one of the pairings,
> "JSynthLibrarian", is almost identical to what we have now).
>
If a name changed very far it could make it hard for people to find the 
project.

I agree that the Lib suffix is confusing for the reason already stated.

My vote would be to refer to it in documentation, release notes etc, as 
JSynthLibrarian, while keeping the domain name / sf project name the same.

frankie

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

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

On 9/23/2011 8:17 AM, Vladimir Avdonin wrote:
> Hey, maybe this would be good moment to maybe contemplate on maybe
> uhmm... name change?

Actually, when we're on the verge of actually getting control of the 
domain... that would be the *last* time to contemplate it. :) The time 
to contemplate it is when Brian has the domain paid up for years and 
doesn't get back to us... or when a domain-squatter gets a hold of it 
and wants a lot of money.

But, now that you've mentioned it...

> JSynthLib sounds like library, not application. For this reason I passed
> by it in searches when looking for synth applications.
>
> How about SynthJ for the first contest entry?

I like that it's short, but it's still a little cryptic.

I'm thinking that we might want some combination of two words: what it 
does stuff *with*, and what it *does* with them. Off the top of my head, 
only two words for each category come to mind:
(Sysex|Synth)(Manager|Librarian)

And then an optional "J" at the front. So, we could have something like 
"JSysexManager" (and, yes, I realize that one of the pairings, 
"JSynthLibrarian", is almost identical to what we have now).

Anyway, just a thought.

- Joe

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

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

Hey, maybe this would be good moment to maybe contemplate on maybe 
uhmm... name change?

JSynthLib sounds like library, not application. For this reason I passed 
by it in searches when looking for synth applications.

How about SynthJ for the first contest entry?


On 09/23/2011 10:04 AM, Joe Emenaker wrote:
> Whoops. Sorry. 40 days.
>
> Should we mark our calendar? Or maybe TUCOWS or some other registrar has
> a "grab this for me the moment it becomes available" option...
>
> - Joe
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2dcopy2
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel

-- 
Vladimir

Re: [Jsynthlib-devel] 10th anniversary

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

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

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

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

Yes.

It would be a disaster if a domain squatter got hold of this domain.

Assuming Brian is no longer interested in the project, the best outcome 
is that we have some contact with brian before 40 days, and we can give 
him the money to re-register it and transfer it to one of us.
A worse outcome would be the more expensive redemption period or an 
online auction after the 40 days.
And the worst outcome would be a domain squatter getting the domain.

If I my message sent via sourceforge doesn't get through to brian, is 
there any other email address or other way of contacting him? Maybe 
could write an international letter to the address listed on the domain 
registration - if the postal address is still valid!

frankie

On 09/23/11 16:04, Joe Emenaker wrote:
> Whoops. Sorry. 40 days.
>
> Should we mark our calendar? Or maybe TUCOWS or some other registrar has
> a "grab this for me the moment it becomes available" option...
>
> - Joe
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2dcopy2
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel

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

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

Whoops. Sorry. 40 days.

Should we mark our calendar? Or maybe TUCOWS or some other registrar has 
a "grab this for me the moment it becomes available" option...

- Joe

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

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

On 9/23/2011 7:59 AM, frankster wrote:
> I don't know how autorenew works, but judging by the whois, it looks
> like tucows have got the domain for a bit.

Looks like the grace period at TUCOWS for .org is 30 days...

-------

To renew or “redeem” a domain, please contactyour Domain Provider 
<http://www.tucowsdomains.com/topic/renewal-and-expiration/findprovider>.

Expired domains are held at Tucows for a Grace Period defined by the 
Registry.

*Partial list of Grace Periods:*

  * .COM, .NET, .ORG, .INFO, .BIZ, .US, .NAME, .TV and .CC – 40 days
  * .CA – 30 days
  * .UK domains resolve for 30 days past their expiration date after
    which they no longer reside with Tucows. Your Domain Provider can
    recover the domain for an additional 60 days by placing a transfer
    request for the domain.
  * .CN and .DE – have no Grace Period; they are deleted the day after
    their expiration date

During the Grace Period, all services (such as the website and email) 
cease working until the name is renewed (if and when this happens). As 
well, name server/DNS changes are not possible. When the domain expires 
the DNS is temporarily changed, and a web page explaining the need for 
renewal may be shown. When the domain is renewed, the DNS will be 
changed back to the previous DNS entries.

At the end of the Grace Period one of three things may happen:

  * The domain is marked for deletion, and with most types of domain
    names this will place the domain name enters a“Redemption Period”
    (also called “Pending Delete Restorable”)
    <http://www.tucowsdomains.com/topic/renewal-and-expiration/what-does-redemptionperiod-or-pending-delete-restorable-mean>,
    which is an additional period of time provided to recover the domain
    name. The cost to recover the domain will be more than the cost of a
    renewal, and recovery is only available to the former domain owner.
    The precise time when the domain is finally deleted depends on the
    Registry, but many domains are deleted 30-35 days after entering the
    Redemption Period.
  * A third party expresses interest in the expired domain name via an
    online auctioning system, and when the Grace Period ends, the domain
    is sold to the highest bidder. Domains that are auctioned off cannot
    be renewed or “redeemed”.
  * Tucows acquires the domain name for its private domain portfolio,
    and upon the Grace Period ending, the domain is not deleted. Should
    the former domain name owner inquire about obtaining the domain name
    via their Domain Provider
    <http://www.tucowsdomains.com/topic/renewal-and-expiration/findprovider>,
    the domain can be returned to them in a process similar to
    “redeeming” a domain. Additional recovery and administrative fees
    may apply.

For information on renewing or redeeming your domain name please contact 
your Domain Provider directly 
<http://www.tucowsdomains.com/topic/renewal-and-expiration/findprovider>.

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

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

On 09/23/11 15:53, Joe Emenaker wrote:
> On 9/23/2011 7:43 AM, frankster wrote:
>> I have managed to get copies of info.html, doc.html, project.html and
>> 3 zip files of packages - that's everything I could find apart from
>> synths.html which is in svn) via the wayback machine.
> Yeah... my vote would be for us to register jsynthlib.org (and soon,
> before some domain squatter snatches it). From past experience, it
> sounds like Brian has kinda moved on. I haven't seen him post to the
> list in years. So, I'd like to see us register it, get as much as we can
> from the wayback machine, and then we can update the pages.
>
> - Joe
>
>
I don't know how autorenew works, but judging by the whois, it looks 
like tucows have got the domain for a bit.

Domain ID:D101476210-LROR
Domain Name:JSYNTHLIB.ORG
Created On:19-Sep-2003 08:11:39 UTC
Last Updated On:23-Sep-2011 02:53:47 UTC
Expiration Date:19-Sep-2012 08:11:39 UTC
Sponsoring Registrar:Tucows Inc. (R11-LROR)
Status:OK
Status:AUTORENEWPERIOD
Registrant ID:tuSz2PZdhcZ8NLlj
Registrant Name:Brian Klock
Registrant Organization:Overwhelmed Organ

frankie

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

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

On 9/23/2011 7:43 AM, frankster wrote:
> I have managed to get copies of info.html, doc.html, project.html and 
> 3 zip files of packages - that's everything I could find apart from 
> synths.html which is in svn) via the wayback machine.

Yeah... my vote would be for us to register jsynthlib.org (and soon, 
before some domain squatter snatches it). From past experience, it 
sounds like Brian has kinda moved on. I haven't seen him post to the 
list in years. So, I'd like to see us register it, get as much as we can 
from the wayback machine, and then we can update the pages.

- Joe

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

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

On 09/23/11 14:07, frankster wrote:
> 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
>
>
So I've emailed Brian Klock via sourceforge to let him know that the 
website has gone down and to find out if he's still got time for or is 
interested in jsynthlib.

If he's not interested any more or doesn't reply, maybe we should set up 
mediawiki on the sourceforge project web page and duplicate the existing 
documentation on there? I have managed to get copies of info.html, 
doc.html, project.html and 3 zip files of packages - that's everything I 
could find apart from synths.html which is in svn) via the wayback machine.

frankie