grig/Lobby

jobf

@jobf

wondering if that might be better in grig.midi too, to return an UnknownEvent instead of throw "Invalid meta event type"

or simply skip over the unknown message

since midi files are weird

and could have all sorts in there

jobf

@jobf

anyway the class I've added for the PortPrefixEvent does seem to work, gonna make sure with some test though still

turns out the editor I was using for the test mid file was breaking it in other ways too!

jobf

@jobf

notice that the return on write here is 5, should it be 4?
https://gitlab.com/haxe-grig/grig.midi/-/blob/main/src/grig/midi/file/event/ChannelPrefixEvent.hx

jobf

@jobf

turns out the editor I was using for the test mid file was breaking it in other ways too!

correction - this mid file started off junk XD

though it is readable by everything I've thrown it at so far

I have tracked down where it's tripping up in grig.midi, will try see what can be done

Thomas J. Webb

@thomasjwebb

There are multiple types of midi files so it could be that it doesn't read that type. And yeah having unknown type makes more sense. That's how grig.osc works.

jobf

@jobf

issue I'm seeing with it is that the file read position ends up out by two bytes, so the midi track header is read wrong
should be 4D 54 72 6B
but is read as 72 6B 00 00
the 4D 54 is there in the stream just the water has already moved on ;)

jobf

@jobf

I'll get the merge request for PortPrefixEvent in today probably, happy it works now just got the query about the Int returns from the write function

Thomas J. Webb

@thomasjwebb

Ok thanks. I can look at the file issue if you e-mail me some files that don’t work. I can add tests for that.

jobf

@jobf

great, I've added the dodgy file I have as an attachment to the merge request

thanks for an awesome set of libs (っ^‿^)っ

Thomas J. Webb

@thomasjwebb

Awesome! Thanks for the PR. I’ll look at it tonight.

jobf

@jobf

@thomasjwebb I'm looking for ways to create MidiMessage at a higher level than passing raw bytes or int arrays to it, are these currently missing due to a design choice or just not needed yet?

for example I'm after something like this at the moment
function messageOfType(type:MessageType, value:Int):MidiMessage {}

Thomas J. Webb

@thomasjwebb

I just haven’t implemented it yet. I wasn’t sure how I wanted to make it. ofMessageType would be good to have. I also need to add the way to go from note to midi note in grig.pitch.

jobf

@jobf

OK cool I've started writing something, was planning to use grig.pitch as well so may look at that too :)

jobf

@jobf

here's what I've done so far, I've totally blown up the number of tests, please let me know if I've gone mad with the validation or indeed any other feedback :)

https://gitlab.com/jamesobfisher/grig.midi/-/tree/feature/midi-construction

jobf

@jobf

absolutely no rush btw

Thomas J. Webb

@thomasjwebb

That looks good to me so far. I'll take a closer look tomorrow. Can you make it as a PR?

jobf

@jobf

So I started to integrate this with my tracker project and it's a bit awkward to use ofMessageType - the parameters I put there kinda create unnecessary work

I'm thinking it's preferable to simplify the parameters to?values:Array<Int> instead of ?value1:Int, ?value2:Int

I'll edit it a bit before I send a merge request.

and soooon I will have cobbled together a basic midi tracker interface, oh yes. Like it's 1999 :joy_cat:

although in 2020 there is this :heart_eyes_cat: http://miditracker.org/

Thomas J. Webb

@thomasjwebb

Nice! I’ve been playing with a tracker for making a chiptune (opl3) remix of one of my songs. I should use miditracker.org!

jobf

@jobf

opl3 ftw

for years I wanted a tracker that I could define rules for instruments that only speak obscure sysex messages

looks like this synergy tracker might be able to handle it, worth digging into for sure

not going to put me off writing my own tracker though, been playing with ideas for too long already :sweat_smile:

Thomas J. Webb

@thomasjwebb

I’m almost tempted to use macros to generate convenience functions for every type. It could even bypass having to call the midi type to byte function at runtime.

jobf

@jobf

oh? sounds fancy :D

jobf

@jobf

something I'd love to see in Haxe is the ability to have functions with the same name but different parameters

so you could have a bunch of different constructors for example

Thomas J. Webb

@thomasjwebb

Yeah overloading. Just like C++. Someone made a macro that allows that I think but yeah that would have been a useful language feature.

jobf

@jobf

ok tidied it up, it's much nicer now imho

I've also got this here in MidiFile, and a similar function in MidiTrack but no tests yet

    public static function fromTracks(tracks:Array<MidiTrack>):MidiFile {
        var f = new MidiFile();
        f.tracks = tracks;
        return f;
    }

so not pushed yet

Thomas J. Webb

@thomasjwebb

Okay I pushed some changes to optimize things a little bit. I hope it doesn't break too much for you. The main breaking change is I moved the function to get MessageType from bytes from MidiMessage to MessageType. The latter is now an abstract enum so it doesn't have to convert the enum to the flag (only the other way around).

Didn't you have some files that don't read right though? I think the problem might be that I never implemented running status. Or never checked that it works right.

jobf

@jobf

Okay I pushed some changes to optimize things a little bit. I hope it doesn't break too much for you. The main breaking change is I moved the function to get MessageType from bytes from MidiMessage to MessageType. The latter is now an abstract enum so it doesn't have to convert the enum to the flag (only the other way around).

that's cool I considered doing that too; making the enum abstract :) the changes look great

Didn't you have some files that don't read right though? I think the problem might be that I never implemented running status. Or never checked that it works right.

the file is here, https://gitlab.com/haxe-grig/grig.midi/uploads/b7f1cb9a961e662fdf2bafd2c5a934b7/asteroid_dance_part_1.mid

Thomas J. Webb

@thomasjwebb

Oh thanks I'll look at that

I need to finish my changes to grig.audio too... but I was thinking it would be cool down the road to support tracker formats and such too.

Thomas J. Webb

@thomasjwebb

Okay I fixed that. Now it can open that and probably most of the other midi files. It was just what I thought, it didn't handle running statuses correctly (it still read the extra byte). My previous changes also should fix some issues with sysex messages. It was fully ignoring them before but now it reads them in case one wants to use it. I did create an issue for saving running status. It's not a big deal on modern machines, but it would make for more compact midi files if it used running status when saving too.

Note that since OSC's midi type uses a fixed size for midi messages, it doesn't have a way of sending sysex dumps that are greater than 4 bytes long, if you wanted to send sysex midi over OSC for whatever reason hehe.

jobf

@jobf

Cool, glad it was simple :)

I'm intrigued about these grig.audio changes, gonna take a look

jobf

@jobf

oh cpp changes

Thomas J. Webb

@thomasjwebb

Yeah there's a lot I haven't uploaded yet but yeah it's firstly stuff to just fix the crash caused by not registering the thread with the gc, but also I ended up changing up the AudioBuffer and AudioChannel interfaces a lot and added the ability to use the same interface for interleaved audio or channels. I already fixed the cpp issue so what's taking time is me trying to decide how the interface works.

Where communities thrive

People

Repo info

Activity