octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: midi functions


From: John Donoghue
Subject: Re: midi functions
Date: Sat, 30 Nov 2019 08:39:42 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2

On 11/30/19 4:11 AM, Olaf Till wrote:
On Fri, Nov 29, 2019 at 12:37:18PM -0500, John Donoghue wrote:
On 11/29/19 11:50 AM, Juan Pablo Carbajal wrote:
Deatr John,

I thought I had enough permission, but it seems I do not.

I opened a ticket so admins can see it
https://sourceforge.net/p/octave/package-releases/394/

I am CC'ing them as well.

On Fri, Nov 29, 2019 at 5:21 PM Juan Pablo Carbajal
<address@hidden> wrote:
forgot one item,

mercurial or git?

On Fri, Nov 29, 2019 at 4:22 PM John Donoghue
<address@hidden> wrote:
On 11/29/19 8:17 AM, Juan Pablo Carbajal wrote:
Ive added some more updates to the patch ticket, can someone create a hg
repo on octave-forge for it?
What name do you want for the package?

Do you want it to be a community or an external package?
midi or midi-toolkit

community


thanks for trying! Ill follow up on the ticket
I was in a probably similar situation with 'database', which I'd have
planned to release as 'postgresql'. It was suggested to make a
'database' package of it, even if it currently only contains code for
postgresql. Contributing code for further database systems later was
allowed for (but as yet no code contributions for further SQL-systems
appeared).

With a similar argumentation, it could be suggested that you maintain
the (currently unmaintained) 'audio' package, remove all the
(unmaintained) code, add your MIDI code and note somewhere that the
package currently only contains MIDI code and maybe that contributions
of other code are welcome and could be based on unmaintained code in
older repository versions. (This would be more like in Matlab, which
has an 'Audio' toolbox containing MIDI code.)

OTOH, this could make the MIDI code more difficult to maintain.

I think we first should give some thought to this principal decision
and hope for some input. The final decision, I think, should be left
to you.

Olaf


It doesnt matter to me whether it goes into the audio package - it may prevent some confusion on what toolkit to use for midi if it matches the matlab scheme.

Of course the other argument could be, that it will only ever contain midi code so should be named midi :)

Looking at the audio toolkit code, it looks like some of the functions were core audio ones that moved to octave core, the others dont seem to be functions in the matlab audio toolkit, so if I used the audio package, I would remove them, unless I found some reference where they are still being used. Unless someone gets all excited about that ;)

I guess I'll wait a little to see if anyone has strong opinions one way or the other.


JD





reply via email to

[Prev in Thread] Current Thread [Next in Thread]