11 Jun
2009
11 Jun
'09
10:20 a.m.
lasconic wrote:
I took some time yesterday night to take a look to
improvisor code and
estimate the cost of adding musicXML export. Import is indeed more
complicated.
I downloaded the code of improvisor 3.39. It's the last and only code
available. Improvisor inner model is a little bit different than musicXML
one. Common practice in musicXML is to don't "time" the chords and put
them
in the middle of notes. At least, this is my experience with finale musicXML
export features.
I managed to make a quick and dirty prototype to export a simple melody (no
tuplet) and chord root and bass (no extension yet). Chords are in between
notes but lily+musicML2ly shoud be able to deal with it. Unfortunately, 3.39
is an old version, and according to Bob Keller the code base changed a lot
but it's not public yet.
With some more voices, perhaps we can convince Bob Keller and his team to
open up the repository to the public. After all, improvisor is a fine piece
of software which can benefit from open development, moreover if time and
resources are an issue.
Lasconic
Thanks man. I'll forward this to Bob Keller too.
I think he mentioned in a message that he is willing to give developers
svn access to the recent code.
Bob, could you comment on this?
Kind regards,
\r
11 Jun
11 Jun
11:34 a.m.
New subject: Improvisor lilypond support!?
On Thursday 11 June 2009 08:19:56 Grammostola Rosea wrote:
lasconic wrote:
Really. Last year I found Improvisor and wanted to contribute to it, so I got
in contact with Bob. I made some changes to integrate the application better
into the desktop (on Mac OS X also) and did some initial cleanup.
The reaction I received was less than welcoming. In fact, the message I got
was that they were not interested in really allowing outside developers to
contribute. Thus my changes were never used, or considered as far as I can
tell. What I got was a bunch of excuses about the situation with the
application until finally this Bob guy came straight out and harshly refused
to cooperate on development. I even had to ask numbers of time before I could
finally get the source code and this resulted in it finally being posted on
the group.
Basically the group that works on it is his student research group at the
educational institution he is employed at. So it appears that they just want
to keep all the glory and credit for the application to themselves by
disallowing outside contributions. This is really not manner that we usually
associate with FOSS. The fact that you have to subscribe to a user group
even to get the binary is one big clue. To my mind the only reason it is under
GPL is because they use other libraries that are, not because they see some
benefit to doing so.
The only way to go with this application, at the moment, is to fork it. I was
considering doing this a while ago, but have other projects keeping me busy.
If you can convince them to open it up, great. I wouldn't hold my breath
though. If enough other developers are interested then I could give some time
to a fork.
Raymond
I took some time yesterday night to take a look
to improvisor code and
estimate the cost of adding musicXML export. Import is indeed more
complicated.
I downloaded the code of improvisor 3.39. It's the last and only code
available. Improvisor inner model is a little bit different than musicXML
one. Common practice in musicXML is to don't "time" the chords and put
them in the middle of notes. At least, this is my experience with finale
musicXML export features.
I managed to make a quick and dirty prototype to export a simple melody
(no tuplet) and chord root and bass (no extension yet). Chords are in
between notes but lily+musicML2ly shoud be able to deal with it.
Unfortunately, 3.39 is an old version, and according to Bob Keller the
code base changed a lot but it's not public yet.
With some more voices, perhaps we can convince Bob Keller and his team to
open up the repository to the public. After all, improvisor is a fine
piece of software which can benefit from open development, moreover if
time and resources are an issue.
Lasconic
Thanks man. I'll forward this to Bob Keller too.
I think he mentioned in a message that he is willing to give developers
svn access to the recent code.
11:51 a.m.
New subject: Improvisor lilypond support!?
raymond wrote:
On Thursday 11 June 2009 08:19:56 Grammostola Rosea
wrote:
This is what he replied me
"If there are developers who are serious, I could provide svn access to
our repository. Right now there are 3 people who are active. We are
about to release version 4, which is almost a year out from version 3.39
that is in the user group. "
So I think we have to go the working together way first.
I've forwarded the message of Lasconic to him, let's wait for his reply
on that.
Kind regards,
\r
lasconic wrote:
Really. Last year I found Improvisor and wanted to contribute to it, so I got
in contact with Bob. I made some changes to integrate the application better
into the desktop (on Mac OS X also) and did some initial cleanup.
The reaction I received was less than welcoming. In fact, the message I got
was that they were not interested in really allowing outside developers to
contribute. Thus my changes were never used, or considered as far as I can
tell. What I got was a bunch of excuses about the situation with the
application until finally this Bob guy came straight out and harshly refused
to cooperate on development. I even had to ask numbers of time before I could
finally get the source code and this resulted in it finally being posted on
the group.
Basically the group that works on it is his student research group at the
educational institution he is employed at. So it appears that they just want
to keep all the glory and credit for the application to themselves by
disallowing outside contributions. This is really not manner that we usually
associate with FOSS. The fact that you have to subscribe to a user group
even to get the binary is one big clue. To my mind the only reason it is under
GPL is because they use other libraries that are, not because they see some
benefit to doing so.
The only way to go with this application, at the moment, is to fork it. I was
considering doing this a while ago, but have other projects keeping me busy.
If you can convince them to open it up, great. I wouldn't hold my breath
though. If enough other developers are interested then I could give some time
to a fork.
I took some time yesterday night to take a look
to improvisor code and
estimate the cost of adding musicXML export. Import is indeed more
complicated.
I downloaded the code of improvisor 3.39. It's the last and only code
available. Improvisor inner model is a little bit different than musicXML
one. Common practice in musicXML is to don't "time" the chords and put
them in the middle of notes. At least, this is my experience with finale
musicXML export features.
I managed to make a quick and dirty prototype to export a simple melody
(no tuplet) and chord root and bass (no extension yet). Chords are in
between notes but lily+musicML2ly shoud be able to deal with it.
Unfortunately, 3.39 is an old version, and according to Bob Keller the
code base changed a lot but it's not public yet.
With some more voices, perhaps we can convince Bob Keller and his team to
open up the repository to the public. After all, improvisor is a fine
piece of software which can benefit from open development, moreover if
time and resources are an issue.
Lasconic
Thanks man. I'll forward this to Bob Keller too.
I think he mentioned in a message that he is willing to give developers
svn access to the recent code.
5600
days inactive
5600
days old
linux-audio-dev@lists.linuxaudio.org
2 comments
2 participants
participants (2)
-
Grammostola Rosea -
raymond