-----Original Message-----
From: Lars Kindermann [mailto:address@hidden]
Sent: Sunday, December 01, 2019 8:57 AM
To: John Donoghue; Olaf Till
Cc: address@hidden; Mike Miller
Subject: Re: midi functions
Am 30.11.19 um 14:39 schrieb John Donoghue:
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
I would opt for a separate midi package at the moment, implementing the
matlab compatible functionality and perhaps some other midi related
stuff, like better midi file handling, GM instrument lists, transposing
and digitizing and maybe some interfaces to open-source midi software.
I don't see anything comparable to the full featured matlab audio
toolbox to become available in the near future. Apart from the signal
processing algorithms, which may be implemented in octave straight
forward, its most interesting functionality spans from low level
hardware support for pro audio and scientific equipment, real time & low
latency multi channel audio handling, VST plugin support - both as host
and client - to deep learning algorithms and speech recognition. It is
basically a complete DAW under the hood with all the hardware and timing
related difficulties which may take several man-years to re-implement.
Keeping functionality apart will make the packages much easier to
maintain imho.
Lars