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

Re: [Jsynthlib-devel] Name for refactored branch

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

On 09/02/2011 11:25 AM, Joachim wrote:
> Hi,
>
>   >  I could think of three directories: fixes, features, users.
>
> Normally branches are made for different releases. I don't see
> a benefit in these three suggested branches as bug fixes have to
> be merged with new features anyway. The users branch is a concept
> I didn't get.
>

Oh, those are not branches themselves, those would be just directories 
to organize branches of similar purpose together.

Probably use examples would help to justify.

Fixes is easy one - each branch in there could be for an accepted bug in 
bug tracker. It would leave there until the fix is tested and accepted 
at which point changes merge to trunk and branch is deleted.

Feature is also more or less clear. Say a major feature effort is 
undertaken, like adding visual themes for example. Several people would 
work on that, and it might be not clear at start towards what release it 
will be targeted, or even when it would be completed. And at the 
beginning it probably would break everything in the project. It will 
eventually be implemented at which point it would merge to either trunk, 
or pre-release brunch, and changes will be deleted.

For users I would illustrate it like this - suppose I got some stupid 
idea that i am not even sure it make sense, but I want to try it anyway. 
Like, say, adding sequencer. It would not fit in features in my view, 
because not everyone would agree that the project needs such feature at 
all. The features would have only agreed lines of development. Users are 
free to put anything in their personal branches. The advantage would be 
capturing any potentially useful development.

Anyway, this all is just suggestion. I would not insist on any

-- 
Vladimir

Re: [Jsynthlib-devel] file download problem

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

Changed the default download to the 0.20 dmg for Mac and
the jar for all other plattforms.

Thanks for the heads up!

Cheers
Joachim

Am 02.09.2011 15:46, schrieb frankster:
> I noticed on the project page
> (https://sourceforge.net/projects/jsynthlib/) that the download button
> goes to CAProvider.jar. And if you click on the files button, it goes to
> a screen with 3 jar files and a message at the top: "Looking for the
> latest version? *Download CAProvider.jar (11.7 kB)
> <http://sourceforge.net/projects/jsynthlib/files/CAProvider/1.1/CAProvider.jar/download>
> "
> *
> As CAProvider and LinuxCharDev are not required by most people, the
> project page should probably be pushing them into downloading jsynthlib.jar.
>
> Is it possible an admin can update the project files to reflect this?
>
> cheers,
> Frankie
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>

Re: [Jsynthlib-devel] Problem diffing build.xml

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

I ran into that problem and got around it by using the --force argument.

But taking the attribute off would also be good IMO, its not like it 
contains any binary data blobs or anything.

frankie

On 09/02/11 17:15, Vladimir Avdonin wrote:
> Hey,
>
> Is anyone else having problem not being able to diff build.xml from svn
> clients. I get this error:
>
> $ svn diff -r 1094 build.xml
> Index: build.xml
> ===================================================================
> Cannot display: file marked as a binary type.
> svn:mime-type = application/xml
>
>
> Apparently this is because of the svn property on that file
> svn:mime-type = application/xml that seem have been there since start of
> time.
>
> Does anybody still need that property on the file for some reason?
>
> If noone will respond, I would remove the property off the file. Or
> anyone cares that it shall be change to mime-type = text/xml?
>

Re: [Jsynthlib-devel] Name for refactored branch

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

Hi,

 > I could think of three directories: fixes, features, users.

Normally branches are made for different releases. I don't see
a benefit in these three suggested branches as bug fixes have to
be merged with new features anyway. The users branch is a concept
I didn't get.

trunk is the somehow the main branch. If we would develop a 0.3 release
this would normally happen in the trunk.
If we decide to make bugfixes for 0.20 a bugfix branch should created
from the trunk before the development for 0.3 begins. It could e.g. be
named rel_0_20_patches/.
A new 0.20 release with bugfixes would then be called 0.20.1 and tagged
rel_0_20_1. This tagged release can then be found in the tags folder.

So branches are there to be able to work parallel on two different
releases. Or to experiment. If the experiment is successful it can
then be merged with the trunk. An experimental refactoring branch
could eg be called 'refactoring_for_0_3' so that the purpose is clear.

Remember that you can always jump back to a specific revision so a
refactoring can also directly be done in the main branch aka trunk.

Cheers
Joachim




Am 02.09.2011 14:22, schrieb frankster:
>
> On 09/02/11 02:06, Vladimir Avdonin wrote:
>> On 09/01/2011 07:54 PM, Joe Emenaker wrote:
>>> Okay, I think I understand Subversion enough to be dangerous.
>>>
>>> I'll need to make a branch to upload my refactored version to. All of
>>> the branches seem to be named after version numbers, but my
>>> understanding is that we can name them anything (like "my_cool_branch").
>>>
>>> Should I name it some step forward in version number (like 0.3,
>>> perhaps), or name it something like "refactor"? What does the group
>>> think is the best way to go on this? Personally, I'd prefer the version
>>> number because, 1) I consider this to be a rather significant step
>>> forward in the "sorting out" of the mess of classes that is the main JSL
>>> codebase (hence, my desire to call it something like v0.3), and 2) it's
>>> more in keeping with the current naming convention in the branch
>>> folder... so it'll be easier for people to see where it fits in with the
>>> rest of the versions.
>>>
>> I  like naming branches in more descriptive way, so if someone would
>> browse repository he could get general idea right from top view.
>>
>> Naming towards release is not very descriptive, and the plans for next
>> release are not documented anywhere.
>>
>> I would also suggest somewhat further structuring of branches directory.
>> You can create subdirectories there based on the purpose of branches
>> inside. I could think of three directories: fixes, features, users.
>>
>> Fixes would be for involved bug resolutions.
>>
>> Features for development extensive changes.
>>
>> Users for developers to fiddle with whatever staff the prefer to work at
>> the moment.
>>
>> In such scheme of things you changes would go into features probably.
>>
>> Just my 2 cents
>>
>> Regards,
>> Vladimir
>>
>> ------------------------------------------------------------------------------
>> Special Offer -- Download ArcSight Logger for FREE!
>> Finally, a world-class log management solution at an even better
>> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
>> download Logger. Secure your free ArcSight Logger TODAY!
>> http://p.sf.net/sfu/arcsisghtdev2dev
>> _______________________________________________
>> Jsynthlib-devel mailing list
>> Jsy...@li...
>> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>
> I agree with Vladimir that without a release plan there's no point
> naming your branch after a release! But when we do decide to do a
> release, normally that's the point at which we will probably be taking a
> copy of the trunk into a branch named after the release. Then typically
> you might let that stabilise for a bit and fix any bugs before making it
> publicly available.
>
> Vladimir's suggestion of creating a "users" subdirectory of branches is
> a good one and that directory can contain branches for any old stuff
> that people are working on, or want to share with others before it gets
> committed into the trunk. Generally it will be tidier if the historic
> release branches are stored in a separate place to any short term
> branches that people might be working on.
>
> But on the subject of release plans, how have releases been decided in
> the past? What triggers them? Who has done them? How is it decided when
> they're ready?
>
> It seems to me that as there are several extra synths supported since
> version 0.20, it would be worth getting some kind of release out
> (perhaps alpha quality / unstable version), so that people can make use
> of the work people have done over the last 6 years! And you never know,
> it might attract a bit more interest in the project as well.
>
> frankie
>
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>

[Jsynthlib-devel] Problem diffing build.xml

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

Hey,

Is anyone else having problem not being able to diff build.xml from svn 
clients. I get this error:

$ svn diff -r 1094 build.xml
Index: build.xml
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/xml


Apparently this is because of the svn property on that file 
svn:mime-type = application/xml that seem have been there since start of 
time.

Does anybody still need that property on the file for some reason?

If noone will respond, I would remove the property off the file. Or 
anyone cares that it shall be change to mime-type = text/xml?

-- 
Vladimir

Re: [Jsynthlib-devel] Separating the synth drivers from JSL (Was: Name for refactored branch)

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

On 09/02/2011 09:38 AM, Joe Emenaker wrote:
> 1 - Will we want to manage the source for JSL and the drivers
> *separately*  at that point? Would we have a branch for every driver, or
> have a branch for*all*  of the drivers? Or is there a better way to do
> this than to use branches?

I would think synthdrivers would move to the top level of repository and 
each driver will get its own build.xml. Whether to use branches in 
development would be up to maintainer of each driver.

I just took a look at jedit repository structure, they actually have 
trunk, branches and tags inside each individual plugin folder. That 
probably make much sense, as each plugin can be project on its own, can 
be taken straight to different repository, or brought to SF repo from 
outside

> 2 - How do we want to*distribute*  the drivers? What I'm getting at here
> is that I think Brian still has control over jsynthlib.org, but he's
> hardly ever here, so I think there's little chance of us being able to
> store the drivers on his server. Do we want to store them on
> SourceForge? Do we want to store them on my server or someone else's? If
> we store it on someone's server, do we want to use some descriptive
> domain name (like jsldrivers.org or something)?

I would think in the application itself that shall be made user 
configurable through preferences. That way independent developers would 
be able to publish their drivers on their own websites.

As for how to handle the projects repository, I donno, maybe that is too 
early to ask this question.

Hey, please do not hide you development. The branch does not need to be 
tidy and compilable. You could dump your work in progress freely on it. 
This way other developers would be able to plug in early. I for one is 
looking forward to get into this development. Looks exciting

-- 
Vladimir

[Jsynthlib-devel] Separating the synth drivers from JSL (Was: Name for refactored branch)

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

On 9/2/2011 5:22 AM, frankster wrote:
> It seems to me that as there are several extra synths supported since
> version 0.20, it would be worth getting some kind of release out
> (perhaps alpha quality / unstable version), so that people can make use
> of the work people have done over the last 6 years! And you never know,
> it might attract a bit more interest in the project as well.

Once I finish this refactor, the next thing I want to set to work on is 
making it so that drivers can be loaded as plugins. This will allow us 
to *not* have to make a new release of JSL in order to get a new driver 
out to the world.

This brings up two questions:
1 - Will we want to manage the source for JSL and the drivers 
*separately* at that point? Would we have a branch for every driver, or 
have a branch for *all* of the drivers? Or is there a better way to do 
this than to use branches?
2 - How do we want to *distribute* the drivers? What I'm getting at here 
is that I think Brian still has control over jsynthlib.org, but he's 
hardly ever here, so I think there's little chance of us being able to 
store the drivers on his server. Do we want to store them on 
SourceForge? Do we want to store them on my server or someone else's? If 
we store it on someone's server, do we want to use some descriptive 
domain name (like jsldrivers.org or something)?

- Joe

[Jsynthlib-devel] file download problem

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

I noticed on the project page 
(https://sourceforge.net/projects/jsynthlib/) that the download button 
goes to CAProvider.jar. And if you click on the files button, it goes to 
a screen with 3 jar files and a message at the top: "Looking for the 
latest version? *Download CAProvider.jar (11.7 kB) 
<http://sourceforge.net/projects/jsynthlib/files/CAProvider/1.1/CAProvider.jar/download> 
"
*
As CAProvider and LinuxCharDev are not required by most people, the 
project page should probably be pushing them into downloading jsynthlib.jar.

Is it possible an admin can update the project files to reflect this?

cheers,
Frankie

Re: [Jsynthlib-devel] patch testing

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

On 09/02/11 12:38, Vladimir Avdonin wrote:
> Frankie:
>
> I was planning to apply my patch for sy77 on a separate branch once I
> get svn access from Joachim. And from there I was thinking to
> investigate how to make a pre-built binary available for download at SF
> for anyone with actual hardware willing to test.
Oh I thought you declined the offer of SVN access because didn't have 
much time to be a developer ;)

>
> I also will try to find time to look through these patches over weekend
> and will report anything I would find worth reporting. I really feel bad
> that you suddenly do so much real work, and I do just talking.

Well all I've really done is a little bit of administration that the 
project needed, and I haven't got very far yet with my driver for the 
Proteus 2000, whereas you have already written a driver for the SY77, so 
you've probably done more real work than me so far!

frankie

Re: [Jsynthlib-devel] Name for refactored branch

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

On 09/02/11 02:06, Vladimir Avdonin wrote:
> On 09/01/2011 07:54 PM, Joe Emenaker wrote:
>> Okay, I think I understand Subversion enough to be dangerous.
>>
>> I'll need to make a branch to upload my refactored version to. All of
>> the branches seem to be named after version numbers, but my
>> understanding is that we can name them anything (like "my_cool_branch").
>>
>> Should I name it some step forward in version number (like 0.3,
>> perhaps), or name it something like "refactor"? What does the group
>> think is the best way to go on this? Personally, I'd prefer the version
>> number because, 1) I consider this to be a rather significant step
>> forward in the "sorting out" of the mess of classes that is the main JSL
>> codebase (hence, my desire to call it something like v0.3), and 2) it's
>> more in keeping with the current naming convention in the branch
>> folder... so it'll be easier for people to see where it fits in with the
>> rest of the versions.
>>
> I  like naming branches in more descriptive way, so if someone would
> browse repository he could get general idea right from top view.
>
> Naming towards release is not very descriptive, and the plans for next
> release are not documented anywhere.
>
> I would also suggest somewhat further structuring of branches directory.
> You can create subdirectories there based on the purpose of branches
> inside. I could think of three directories: fixes, features, users.
>
> Fixes would be for involved bug resolutions.
>
> Features for development extensive changes.
>
> Users for developers to fiddle with whatever staff the prefer to work at
> the moment.
>
> In such scheme of things you changes would go into features probably.
>
> Just my 2 cents
>
> Regards,
> Vladimir
>
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel

I agree with Vladimir that without a release plan there's no point 
naming your branch after a release! But when we do decide to do a 
release, normally that's the point at which we will probably be taking a 
copy of the trunk into a branch named after the release. Then typically 
you might let that stabilise for a bit and fix any bugs before making it 
publicly available.

Vladimir's suggestion of creating a "users" subdirectory of branches is 
a good one and that directory can contain branches for any old stuff 
that people are working on, or want to share with others before it gets 
committed into the trunk. Generally it will be tidier if the historic 
release branches are stored in a separate place to any short term 
branches that people might be working on.

But on the subject of release plans, how have releases been decided in 
the past? What triggers them? Who has done them? How is it decided when 
they're ready?

It seems to me that as there are several extra synths supported since 
version 0.20, it would be worth getting some kind of release out 
(perhaps alpha quality / unstable version), so that people can make use 
of the work people have done over the last 6 years! And you never know, 
it might attract a bit more interest in the project as well.

frankie

Re: [Jsynthlib-devel] patch testing

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

Frankie:

I was planning to apply my patch for sy77 on a separate branch once I 
get svn access from Joachim. And from there I was thinking to 
investigate how to make a pre-built binary available for download at SF 
for anyone with actual hardware willing to test.

But in general synth drivers are very much self contained and should not 
touch anything outside their directory. If a new one does not break the 
build process, and does not crash the program at startup, then I would 
think they are quite safe to add and leave further testing to interested 
parties.

Of course there is always chance that new ones will interfere with 
existing working ones, breaking both in some hardware configurations. 
But that would probably be much harder to catch by reading than by testing.

So I would think quick look through the code should suffice.

I also will try to find time to look through these patches over weekend 
and will report anything I would find worth reporting. I really feel bad 
that you suddenly do so much real work, and I do just talking.

Thanks for you effort.

Vladimir

On 09/02/2011 05:18 AM, frankster wrote:
> So last night I've put in 2 patches that I made, and 2 patches that
> other people made. They were all quite small patches and it was possible
> for me to test them all. There are (at least) 3 more substantial patches
> available that its not really possible for me to test as they are
> drivers for hardware that I don't own. They are:
> 1) Vladimir's support for Yamaha SY77
> 2) Chris Arndt's partial support for Yamaha SY85 (that has sat in the
> patch queue for 2 years!)
> 3) Fred Jan Kraan's updated MT-32 driver and rudimentary driver for
> Lexicon LXP5 that he mentioned yesterday.
>
> I'm inclined to give them a read through over the weekend to check there
> are no horror stories lurking inside and then commit them.
>
> Any objections?
>
> Frankie
>
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel

-- 
Regards,
Vladimir

[Jsynthlib-devel] patch testing

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

So last night I've put in 2 patches that I made, and 2 patches that 
other people made. They were all quite small patches and it was possible 
for me to test them all. There are (at least) 3 more substantial patches 
available that its not really possible for me to test as they are 
drivers for hardware that I don't own. They are:
1) Vladimir's support for Yamaha SY77
2) Chris Arndt's partial support for Yamaha SY85 (that has sat in the 
patch queue for 2 years!)
3) Fred Jan Kraan's updated MT-32 driver and rudimentary driver for 
Lexicon LXP5 that he mentioned yesterday.

I'm inclined to give them a read through over the weekend to check there 
are no horror stories lurking inside and then commit them.

Any objections?

Frankie

Re: [Jsynthlib-devel] DX7 Editor problem

[Martin T. <m.t...@zo...>]

On Thu, 1 Sep 2011, frankster wrote:

> Martin Tarenskeen reported a problem a month ago to this list (which I can't reply to because I wasn't a member of the list then).
>
>> 4. In the CVS version the DX7 editor does not open, I am getting an error
>> message instead. The DX7 editor is working fine in 0.20.0 version.
>
> I've committed a patch based on the one he proposed to the SVN trunk.

Great to see JSynthlib-devel coming to life again! There could still be a 
future for our beloved JSynthlib!

MT

Re: [Jsynthlib-devel] Name for refactored branch

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

On 09/01/2011 07:54 PM, Joe Emenaker wrote:
>
> Okay, I think I understand Subversion enough to be dangerous.
>
> I'll need to make a branch to upload my refactored version to. All of
> the branches seem to be named after version numbers, but my
> understanding is that we can name them anything (like "my_cool_branch").
>
> Should I name it some step forward in version number (like 0.3,
> perhaps), or name it something like "refactor"? What does the group
> think is the best way to go on this? Personally, I'd prefer the version
> number because, 1) I consider this to be a rather significant step
> forward in the "sorting out" of the mess of classes that is the main JSL
> codebase (hence, my desire to call it something like v0.3), and 2) it's
> more in keeping with the current naming convention in the branch
> folder... so it'll be easier for people to see where it fits in with the
> rest of the versions.
>

I  like naming branches in more descriptive way, so if someone would 
browse repository he could get general idea right from top view.

Naming towards release is not very descriptive, and the plans for next 
release are not documented anywhere.

I would also suggest somewhat further structuring of branches directory. 
You can create subdirectories there based on the purpose of branches 
inside. I could think of three directories: fixes, features, users.

Fixes would be for involved bug resolutions.

Features for development extensive changes.

Users for developers to fiddle with whatever staff the prefer to work at 
the moment.

In such scheme of things you changes would go into features probably.

Just my 2 cents

Regards,
Vladimir

[Jsynthlib-devel] Name for refactored branch

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

Okay, I think I understand Subversion enough to be dangerous.

I'll need to make a branch to upload my refactored version to. All of 
the branches seem to be named after version numbers, but my 
understanding is that we can name them anything (like "my_cool_branch").

Should I name it some step forward in version number (like 0.3, 
perhaps), or name it something like "refactor"? What does the group 
think is the best way to go on this? Personally, I'd prefer the version 
number because, 1) I consider this to be a rather significant step 
forward in the "sorting out" of the mess of classes that is the main JSL 
codebase (hence, my desire to call it something like v0.3), and 2) it's 
more in keeping with the current naming convention in the branch 
folder... so it'll be easier for people to see where it fits in with the 
rest of the versions.

- Joe

[Jsynthlib-devel] DX7 Editor problem

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

Martin Tarenskeen reported a problem a month ago to this list (which I can't reply to because I wasn't a member of the list then).

> 4. In the CVS version the DX7 editor does not open, I am getting an error
> message instead. The DX7 editor is working fine in 0.20.0 version.

I've committed a patch based on the one he proposed to the SVN trunk.

Frankie

[Jsynthlib-devel] SVN should now be buildable

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

I have committed fixes to SVN for the errors that until recently
occurred if you run "ant" or "make".

frankie

Re: [Jsynthlib-devel] Required java version for JSL?

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

There was a build problem for the Roland D10 in SVN when building with
ant, as the build.xml stated 1.4 however it used constructs from Java 5.
So I have changed the build.xml to state 1.5 in order to make it
buildable without error.  Thus unofficially, it already requires 1.5.

Whether changing the build.xml is the correct approach, or "fixing" the
D10 driver would be, I don't know.  I suppose it depends whether there
are systems that aren't supported by Java 1.5, otherwise the advances in
the language would be nice to rely on 

frankie


On 01/09/2011 19:13, Joe Emenaker wrote:
> So, I'm looking through my JSL code (looks like I last touched it was 
> 2006 or 2007... oy!). I'm finding some places which could be updated to 
> using the newer java collections (like ArrayList, HashMap, etc.) as well 
> as a few spots which could use the newer Java "foreach" loop.
>
> I think those all require Java 5 or later.
>
> Have we decided what version of Java is officially "required" by JSL 
> these days?
>
> - Joe
>
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better 
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel

[Jsynthlib-devel] Required java version for JSL?

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

So, I'm looking through my JSL code (looks like I last touched it was 
2006 or 2007... oy!). I'm finding some places which could be updated to 
using the newer java collections (like ArrayList, HashMap, etc.) as well 
as a few spots which could use the newer Java "foreach" loop.

I think those all require Java 5 or later.

Have we decided what version of Java is officially "required" by JSL 
these days?

- Joe

Re: [Jsynthlib-devel] synth support that's not made it into SVN!!

[F.J. K. <fj...@xs...>]

Hi,

At http://electrickery.xs4all.nl/digaud/mt32/ is a more recent version 
of the Roland MT-32 driver. Still incomplete. There is also a 
rudimentary driver for the Lexicon LXP5. It shows the settings of a 
patch, which is not possible on the LXP5 itself.

I didn't touch the code or tested it with the devices in quite some 
time, so add an warning ;-).

Greetings,

Fred Jan

Re: [Jsynthlib-devel] fixed build error in trunk

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

On 09/01/2011 12:01 PM, Joe Emenaker wrote:
> On 9/1/2011 7:49 AM, Vladimir Avdonin wrote:
>> Regarding you experimental work:
>>
>> The mechanism for such activity provided by subversion is branch. Once you created you branch you can screw it around in any way you please, it would not affect main line of development and releases. Once your branch would arrive to some agreeable good state, it can be merged back into trunk for common use.
>
> The only problem with that is that, back when I started it, Sourceforge wasn't using SVN, it was using CVS. SVN understands files getting *moved* to other folders, while CVS treats them as though you deleted the old file and created a new one in the new location. So, the revision history gets "broken", in a way.
>
> I'm now worried that, if I try to make a branch, SVN won't understand any continuity from the existing source tree, and it will consider the entire source code to be new.... which would make for an interesting merge into the trunk, later.
>
> But I know almost nothing about how SVN does it's thing...
>
> - Joe

Subversion is much better at that than cvs. You can keep updating your branch with changes from trunk - or any other branch for that matter. And eventually goal of any branch is to be merged back to trunk, which also works well. So continuity is not lost in either direction.

Take a look at these chapter from svn book -- it is not very long reading.

http://svnbook.red-bean.com/en/1.0/ch04.html

Regards,
Vladimir

Re: [Jsynthlib-devel] fixed build error in trunk

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

On 09/01/2011 11:44 AM, Joachim wrote:
> I tried but I didn't find your SourceForge user. If you mail it to me (off-list)
> or to the list I'm able to add you.


Thanks, but I am not sure the amount of effort I could currently afford to contribute to the project would justify adding me as a developer now.

I would stick around and use patch submission when needed for now. If I really find myself later involved in lots of code changes, then I would ask to be added

Regards,
Vladimir

Re: [Jsynthlib-devel] fixed build error in trunk

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

On 9/1/2011 7:49 AM, Vladimir Avdonin wrote:
> Regarding you experimental work:
>
> The mechanism for such activity provided by subversion is branch. Once you created you branch you can screw it around in any way you please, it would not affect main line of development and releases. Once your branch would arrive to some agreeable good state, it can be merged back into trunk for common use.

The only problem with that is that, back when I started it, Sourceforge 
wasn't using SVN, it was using CVS. SVN understands files getting 
*moved* to other folders, while CVS treats them as though you deleted 
the old file and created a new one in the new location. So, the revision 
history gets "broken", in a way.

I'm now worried that, if I try to make a branch, SVN won't understand 
any continuity from the existing source tree, and it will consider the 
entire source code to be new.... which would make for an interesting 
merge into the trunk, later.

But I know almost nothing about how SVN does it's thing...

- Joe

Re: [Jsynthlib-devel] fixed build error in trunk

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

Thanks for adding me.

FYI: You can see Vladimir's user name from the 2 patches he put in the 
patch tracker: https://sourceforge.net/tracker/?group_id=41208&atid=430006

Cheers,
Frankie

On 09/01/11 17:44, Joachim wrote:
> Vladimir,
>
>   >  Did any other admins objected? Or it just did not work technically?
>
> I tried but I didn't find your SourceForge user. If you mail it to me (off-list)
> or to the list I'm able to add you.
>
> Cheers
> Joachim
>
> Am 01.09.2011 16:49, schrieb Vladimir Avdonin:
>> Joe,
>>
>> You are listed as project admin. Did you ever try adding anyone to svn access?
>>
>> Few months ago you said you could add me to the project, but that ended with nothing. Did any other admins objected? Or it just did not work technically?
>>
>> Regarding you experimental work:
>>
>> The mechanism for such activity provided by subversion is branch. Once you created you branch you can screw it around in any way you please, it would not affect main line of development and releases. Once your branch would arrive to some agreeable good state, it can be merged back into trunk for common use.
>>
>> If you would put you refactoring effort on the branch 4 years ago, there would be a good chance someone could pick it up and help you finish it. When i was working on driver code, I was wondering on some design choices for class hierarchy, and I was very itchy myself to refactor the code. I decided to hold my horses until I could at least discuss that with main developers.
>>
>> So, please, create a branch for refactoring and commit you work there. It would be a shame to waste that effort.
>>
>> Regard,
>> Vladimir
>>
>> On 08/31/2011 10:40 PM, Joe Emenaker wrote:
>>> On 8/31/2011 4:14 PM, Michael Hawkins wrote:
>>>> I ran into some rather tough jsynthlib admin's a couple of years back. I think it was you Bill!
>>> I don't think Bill is an "admin" (in the sense that he can't authorize
>>> people to upload to the svn repository); I think only Joachim and Brian
>>> are. The rest of us (about 15 others) have write-access to the svn, but
>>> we can't add people.
>>>
>>>> The only thing that drives me nuts about jsynthlib is the maddening process of laying out widgets. There simply has to be either better documentation on it or a better way of doing it. But maybe I just still don't know what I am doing!
>>> About 4 years ago, I started on a massive (for me) re-factoring of the
>>> code. I moved everything into packages which compartmentalized what
>>> everything did (ie, a package for low-level MIDI message handling, a
>>> package for the main GUI, a package for the widgets, etc.). The two big
>>> hurdles were:
>>> 1 - Rewriting the low-level MIDI stuff. As I recall, sending and polling
>>> for MIDI signals was done with the GUI thread or something, so I made a
>>> new thread which would handle all queuing of MIDI messages and notify
>>> various sysex handlers that something had come in for them, etc. It made
>>> it so that I could write a little MIDI monitor window to watch incoming
>>> traffic, etc.
>>> 2 - Re-vamping the hierarchy of the JSynthlib widgets. It turns out that
>>> the basic JSynthlib window was named something strange, which made it
>>> hard to get up to speed on how to make a new synth-lib module.
>>>
>>> Anyway, as you can imagine, with a huge refactor like that, there were
>>> tons of compile errors as I changed around the way things were invoked,
>>> etc. When I ran out of steam on it, I think there were still a handful
>>> of errors that I couldn't really figure out how to best solve... so I
>>> never committed the changes.
>>>
>>> Since the project is so dormant, I'm tempted to dig the code up again
>>> and commit it just to see if it generates some renewed interest...
>>>
>>> - Joe
>>>
>>> ------------------------------------------------------------------------------
>>> Special Offer -- Download ArcSight Logger for FREE!
>>> Finally, a world-class log management solution at an even better
>>> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
>>> download Logger. Secure your free ArcSight Logger TODAY!
>>> http://p.sf.net/sfu/arcsisghtdev2dev
>>> _______________________________________________
>>> Jsynthlib-devel mailing list
>>> Jsy...@li...
>>> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>>
>> ------------------------------------------------------------------------------
>> Special Offer -- Download ArcSight Logger for FREE!
>> Finally, a world-class log management solution at an even better
>> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
>> download Logger. Secure your free ArcSight Logger TODAY!
>> http://p.sf.net/sfu/arcsisghtdev2dev
>> _______________________________________________
>> Jsynthlib-devel mailing list
>> Jsy...@li...
>> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>>
>
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel

Re: [Jsynthlib-devel] fixed build error in trunk

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

Vladimir,

 > Did any other admins objected? Or it just did not work technically?

I tried but I didn't find your SourceForge user. If you mail it to me (off-list)
or to the list I'm able to add you.

Cheers
Joachim

Am 01.09.2011 16:49, schrieb Vladimir Avdonin:
> Joe,
>
> You are listed as project admin. Did you ever try adding anyone to svn access?
>
> Few months ago you said you could add me to the project, but that ended with nothing. Did any other admins objected? Or it just did not work technically?
>
> Regarding you experimental work:
>
> The mechanism for such activity provided by subversion is branch. Once you created you branch you can screw it around in any way you please, it would not affect main line of development and releases. Once your branch would arrive to some agreeable good state, it can be merged back into trunk for common use.
>
> If you would put you refactoring effort on the branch 4 years ago, there would be a good chance someone could pick it up and help you finish it. When i was working on driver code, I was wondering on some design choices for class hierarchy, and I was very itchy myself to refactor the code. I decided to hold my horses until I could at least discuss that with main developers.
>
> So, please, create a branch for refactoring and commit you work there. It would be a shame to waste that effort.
>
> Regard,
> Vladimir
>
> On 08/31/2011 10:40 PM, Joe Emenaker wrote:
>> On 8/31/2011 4:14 PM, Michael Hawkins wrote:
>>> I ran into some rather tough jsynthlib admin's a couple of years back. I think it was you Bill!
>> I don't think Bill is an "admin" (in the sense that he can't authorize
>> people to upload to the svn repository); I think only Joachim and Brian
>> are. The rest of us (about 15 others) have write-access to the svn, but
>> we can't add people.
>>
>>> The only thing that drives me nuts about jsynthlib is the maddening process of laying out widgets. There simply has to be either better documentation on it or a better way of doing it. But maybe I just still don't know what I am doing!
>> About 4 years ago, I started on a massive (for me) re-factoring of the
>> code. I moved everything into packages which compartmentalized what
>> everything did (ie, a package for low-level MIDI message handling, a
>> package for the main GUI, a package for the widgets, etc.). The two big
>> hurdles were:
>> 1 - Rewriting the low-level MIDI stuff. As I recall, sending and polling
>> for MIDI signals was done with the GUI thread or something, so I made a
>> new thread which would handle all queuing of MIDI messages and notify
>> various sysex handlers that something had come in for them, etc. It made
>> it so that I could write a little MIDI monitor window to watch incoming
>> traffic, etc.
>> 2 - Re-vamping the hierarchy of the JSynthlib widgets. It turns out that
>> the basic JSynthlib window was named something strange, which made it
>> hard to get up to speed on how to make a new synth-lib module.
>>
>> Anyway, as you can imagine, with a huge refactor like that, there were
>> tons of compile errors as I changed around the way things were invoked,
>> etc. When I ran out of steam on it, I think there were still a handful
>> of errors that I couldn't really figure out how to best solve... so I
>> never committed the changes.
>>
>> Since the project is so dormant, I'm tempted to dig the code up again
>> and commit it just to see if it generates some renewed interest...
>>
>> - Joe
>>
>> ------------------------------------------------------------------------------
>> Special Offer -- Download ArcSight Logger for FREE!
>> Finally, a world-class log management solution at an even better
>> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
>> download Logger. Secure your free ArcSight Logger TODAY!
>> http://p.sf.net/sfu/arcsisghtdev2dev
>> _______________________________________________
>> Jsynthlib-devel mailing list
>> Jsy...@li...
>> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>
>
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>