2019-03-14 23:59:10

Continuing my venture to release open source stuff, I was considering publishing a library I wrote a few years ago to parse standard MIDI files. It will not actually play anything, but will give you the individual events in the MIDI file that you can then use to do whatever you like. Just like voclib and blastlibs, this library would be a single file of C code, dual licensed under either the Unlicense or the MIT Zero Attribution license. Is there any interest in this?

Kind regards,

Philip Bennefall

2019-03-15 06:39:35

i am intrusted

2019-03-15 08:24:07

Yes, I definitely do. I quickly dreamed of doing funny audio editing with my midi keyboard. The input might be from a file only though. Anyway, Yes.

I don't speak as good as I write, and I don't listen as good as I speak.

2019-03-15 09:12:09

https://github.com/topics/midi-parser
Will your lib actually bring anything new here?

If you want to contact me, do not use the forum PM. I respond once a year or two, when I need to write a PM myself. I apologize for the inconvenience.
Telegram: Nuno69a
E-Mail: nuno69a (at) gmail (dot) com

2019-03-15 10:28:41

@Post 4:

I had a look at the list, and I can see the following advantages for my library:

* License. The libraries I saw there were either GPL, LGPL or BSD. They all require attribution which I don't like. I believe it is foolish to make users include a bunch of generic legal text in their software simply because they use a specific library internally. This is especially true if you use that library in middleware that others in turn make use of; the license text blob grows huge very quickly.

* A single file library. It can't really get much easier to integrate than that, you just add the file and it works. No build system, etc.

* ANSI C. Not everyone will care about this, but ANSI C is the most portable language I am aware of, which should mean that the code will run more or less anywhere.

Those are the advantages I can see. Of course some of these points won't be important to everyone, but they are to me personally which is why I want to publish libraries in this form.

Kind regards,

Philip Bennefall

2019-03-15 12:46:42

Hey.
Yeah, that makes sense. Just to clarify things, I didn't mean to attack you or your projects. It's great you are making these stuff.

If you want to contact me, do not use the forum PM. I respond once a year or two, when I need to write a PM myself. I apologize for the inconvenience.
Telegram: Nuno69a
E-Mail: nuno69a (at) gmail (dot) com

2019-03-15 14:14:32

Oh no, I didn't take it as an attack. Asking questions about the motivation behind a project is absolutely warrented.

Kind regards,

Philip Bennefall

2019-03-16 20:28:02

Hi Philip,

Having something like this as a dynamic link library would be cool, as there was a bit of software I was working on that could be extended in many ways with something like that.

I've been going by Bryn, which is now reflected in my profile. Please do your best to respect this :) Mess ups are totally OK though, I don't mind and totally understand!
Follow on twitter! @ItsBrynify
Thanks, enjoy, thumbs up, share, like, hate, exist, do what ya do,
my website: brynify.me

2019-03-16 21:10:33 (edited by Ethin 2019-03-16 21:12:31)

I hope this isn't taken as an attack either -- just curiosity. What makes this library better than others like portmidi and rtmidi?
And heh... was actually thinking today about making a generic cryptographic interface to libraries like BearSSL, OpenSSL, LibreSSL, Botan, Libsodium, Crypto++, Monocypher, and so on, something that could be extensible to other libraries. Perhaps we can collaborate, call the library collection "extensible_libs"? Mmm... thoughts? It could be for other things too... take this library, pass that through rtmidi/portmidi...

"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."    — Charles Babbage.
My Github

2019-03-16 22:06:43

@Post 9

I addressed some of the differences between my library and some others in post 5. When it comes to portmidi and rtmidi, they are driver wrappers - not parsers. portmidi and rtmidi will let you talk to MIDI input and output devices, which is quite different from parsing MIDI files. Basically, the output from a MIDI file parser can be sent to portmidi or rtmidi for playback using a MIDI driver on your system.

Kind regards,

Philip Bennefall

2019-03-17 03:37:49

@10, ah. Very nice. So your library acts as the "abstraction" for MIDI file reading, and the data read can then be sent on to MIDI drivers. I like that. Would be happy to make a test program to show how something like rtmidi could be used for those who like "practical" things like that.

"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."    — Charles Babbage.
My Github