midi functions

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

midi functions

John Donoghue-3
All,

I started what could turn into a new package for midi functions based on
the function info provided for matlab.

It is using rtmidi as the library for the midi access, still needs some
work and doesnt have all the functions yet.


I posted to the code onto teh patch tracker [1]

If it looks ok for a start, can someone create a hg repo on octave-forge
for it?

[1] https://savannah.gnu.org/patch/index.php?9868


JD




Reply | Threaded
Open this post in threaded view
|

Re: midi functions

John Donoghue-3
On 11/3/19 8:30 PM, John Donoghue wrote:

> All,
>
> I started what could turn into a new package for midi functions based
> on the function info provided for matlab.
>
> It is using rtmidi as the library for the midi access, still needs
> some work and doesnt have all the functions yet.
>
>
> I posted to the code onto teh patch tracker [1]
>
> If it looks ok for a start, can someone create a hg repo on
> octave-forge for it?
>
> [1] https://savannah.gnu.org/patch/index.php?9868
>
>
> JD
>
>
>
Ive added some more updates to the patch ticket, can someone create a hg
repo on octave-forge for it?


Reply | Threaded
Open this post in threaded view
|

Re: midi functions

Juan Pablo Carbajal-2
> 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?

Reply | Threaded
Open this post in threaded view
|

Re: midi functions

John Donoghue-3
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



Reply | Threaded
Open this post in threaded view
|

Re: midi functions

Juan Pablo Carbajal-2
forgot one item,

mercurial or git?

On Fri, Nov 29, 2019 at 4:22 PM John Donoghue
<[hidden email]> 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
>
>

Reply | Threaded
Open this post in threaded view
|

Re: midi functions

Juan Pablo Carbajal-2
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
<[hidden email]> wrote:

>
> forgot one item,
>
> mercurial or git?
>
> On Fri, Nov 29, 2019 at 4:22 PM John Donoghue
> <[hidden email]> 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
> >
> >

Reply | Threaded
Open this post in threaded view
|

Re: midi functions

John Donoghue-3
In reply to this post by Juan Pablo Carbajal-2
On 11/29/19 11:21 AM, Juan Pablo Carbajal wrote:

> forgot one item,
>
> mercurial or git?
>
> On Fri, Nov 29, 2019 at 4:22 PM John Donoghue
> <[hidden email]> 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
>>
>>
mercurial


Reply | Threaded
Open this post in threaded view
|

Re: midi functions

John Donoghue-3
In reply to this post by Juan Pablo Carbajal-2
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
> <[hidden email]> wrote:
>> forgot one item,
>>
>> mercurial or git?
>>
>> On Fri, Nov 29, 2019 at 4:22 PM John Donoghue
>> <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: midi functions

Olaf Till-2
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
> > <[hidden email]> wrote:
> > > forgot one item,
> > >
> > > mercurial or git?
> > >
> > > On Fri, Nov 29, 2019 at 4:22 PM John Donoghue
> > > <[hidden email]> 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

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: midi functions

John Donoghue-3
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
>>> <[hidden email]> wrote:
>>>> forgot one item,
>>>>
>>>> mercurial or git?
>>>>
>>>> On Fri, Nov 29, 2019 at 4:22 PM John Donoghue
>>>> <[hidden email]> 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 | Threaded
Open this post in threaded view
|

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
>>>> <[hidden email]> wrote:
>>>>> forgot one item,
>>>>>
>>>>> mercurial or git?
>>>>>
>>>>> On Fri, Nov 29, 2019 at 4:22 PM John Donoghue
>>>>> <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

RE: midi functions

John Donoghue-3


> -----Original Message-----
> From: Lars Kindermann [mailto:[hidden email]]
> Sent: Sunday, December 01, 2019 8:57 AM
> To: John Donoghue; Olaf Till
> Cc: [hidden email]; 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
> >>>> <[hidden email]> wrote:
> >>>>> forgot one item,
> >>>>>
> >>>>> mercurial or git?
> >>>>>
> >>>>> On Fri, Nov 29, 2019 at 4:22 PM John Donoghue
> >>>>> <[hidden email]> 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


So one vote for use audio
One for midi
 and one doesnt matter to me

I guess there is no reason why the audio toolkit cant be a toolkit that only contains implemented midi code and none of the audio parts (assuming no one else adds it) and can still contain features that matlab doesn’t have (for starters the rudimentary file handling I have isn’t in matlab)


Reply | Threaded
Open this post in threaded view
|

Re: midi functions

John Donoghue-3
On 12/4/19 9:55 AM, JohnD wrote:

>
>> -----Original Message-----
>> From: Lars Kindermann [mailto:[hidden email]]
>> Sent: Sunday, December 01, 2019 8:57 AM
>> To: John Donoghue; Olaf Till
>> Cc: [hidden email]; 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
>>>>>> <[hidden email]> wrote:
>>>>>>> forgot one item,
>>>>>>>
>>>>>>> mercurial or git?
>>>>>>>
>>>>>>> On Fri, Nov 29, 2019 at 4:22 PM John Donoghue
>>>>>>> <[hidden email]> 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
>
> So one vote for use audio
> One for midi
>   and one doesnt matter to me
>
> I guess there is no reason why the audio toolkit cant be a toolkit that only contains implemented midi code and none of the audio parts (assuming no one else adds it) and can still contain features that matlab doesn’t have (for starters the rudimentary file handling I have isn’t in matlab)
>
I posted a basic example of the audio package to patch #9868 [1] to
illustrate the package with midi functions added - its pretty much a
rename of what I had in my code to the audio package name, as it seemed
to me that none of the old audio functions were needed anymore - I'm
certainly opened to keeping any of them, if anyone has even a  slight
feeling on wanting them

It would start out as  version 2.0.0 release when it gets to the point
of being released.



[1] https://savannah.gnu.org/patch/index.php?9868#comment12