Re: midi functions

[Lars Kindermann]

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