Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Sep 15 03:00

    osakared-build on main

    Updated haxe version (compare)

  • Aug 26 19:28

    thomasjwebb on master

    (compare)

  • Aug 26 19:25

    osakared-build on main

    Updated grig versions, added ge… (compare)

  • Jul 31 20:58

    osakared-build on main

    Initial commit.. nothing to see… Added license More changes and 7 more (compare)

  • Nov 13 2019 05:02

    osakared-build on master

    Initial commit Add Gitter badge Merge pull request #1 from gitt… and 52 more (compare)

  • Nov 13 2019 05:00

    osakared-build on master

    Initial work on fmod js bindings Finished adding externs to Syst… Added disclaimer (compare)

  • May 09 2019 14:48

    osakared-build on master

    Switched to using haxelib versi… (compare)

  • May 01 2019 04:43

    osakared-build on master

    Added velocity sensitivity back… (compare)

  • May 01 2019 04:36

    osakared-build on master

    Removed files I have no idea ho… (compare)

  • May 01 2019 04:28

    osakared-build on master

    Switched to using entire block … Added EG to MonoFMSynth for a c… Made examples sound a little be… (compare)

  • Apr 30 2019 04:54

    osakared-build on master

    Fading in and out to prevent cl… (compare)

  • Mar 28 2019 04:48

    osakared-build on master

    Added separate fmsynth project (compare)

  • Mar 26 2019 03:07

    osakared-build on master

    Experimenting with simple singl… (compare)

  • Mar 25 2019 02:47

    osakared-build on master

    Updated haxe version and added … Added beginning of MonoSynth ex… Work on MonoSynth example (compare)

  • Mar 10 2019 18:43

    osakared-build on master

    Removed stuff that has been mov… (compare)

  • Feb 18 2019 20:07

    osakared-build on master

    Updated to reflect python pyaud… (compare)

  • Feb 17 2019 04:05

    osakared-build on master

    Added targets that have been im… (compare)

  • Feb 05 2019 06:08

    osakared-build on master

    Downgrading to old lix version … (compare)

  • Nov 28 2018 07:22

    osakared-build on master

    Updated docs with new capabilit… (compare)

  • Nov 15 2018 05:51

    osakared-build on master

    Updated documentation (compare)

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
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.