DSP Robotics Support

This project sprouted here. I was kind of surprised that there was almost no MIDI file support in flowstone, so I decided to cook up something. The general idea is to create ruby module that can load, play, edit and save midi files in accessible way.

This is an early prototype - it can load a midi file and play it (no saving yet, and editing is work in progress). So far it only supports Midi Channel Events (notes, controller changes, program changes, aftertouch etc. ). Other types of events, like SYSEX and Meta Events (signature, tempo change, text,...) are not fully implemented (they are only send through as text notification for logging on the second output).

WOW

Zillion Thanks KG

I was waiting for this one for long time. So happy to see you gave it a shot and I can't wait to test it

I have some midi styles ready for action and I so badly hope your midi file utility will handle it

Hi KG ... did a fast DL and test ... not able to have it play yet.

I did see some data being displayed ... will look in closer.

THANKS

RJHollins wrote:Hi KG ... did a fast DL and test ... not able to have it play yet.

I did see some data being displayed ... will look in closer.

THANKS

Make sure the soundcard is engaged. Midi fires even if soundcard is off. If it is a multitrack file, try selecting different track - it's apparently a common practice for the 0th track to contain only information about the file (like author, name of the song, signature etc.) without any notes.

Upon loading, the logger should show the path to the midi file and some of its properties (number of tracks and format). After you hit play, the logger should list all midi messages going out, including the ones that FS doesn't understand (SYSEX, meta events, etc. ).

For example, here is what the logger shows to me, when I load a file and hit play on track 0 (which apparently only contains 4 meta events)

Code: Select all

File: C:\[CENSORED]\jm_mozdi.mid;
No. of Tracks: 13; format: 1
#<MidiMetaEvent:0x8889f84 @dt=0, @t=0, @type=88, @length=4, @data="\x04\x02\x18\b">
#<MidiMetaEvent:0x8889f48 @dt=0, @t=0, @type=89, @length=2, @data="\x00\x00">
#<MidiMetaEvent:0x8889f0c @dt=0, @t=0, @type=81, @length=3, @data="\x06\x1A\x80">
#<MidiMetaEvent:0x8889ee4 @dt=0, @t=0, @type=47, @length=0, @data=nil>


Format 1 means the file should play all 13 tracks simultaneously.
The first meta event (88) is time signature, second (89) is key signature, third (81) is tempo and the last one (47) is EndOfTrack. The track 0 doesn't actually play anything because there are no notes there. Tracks 1..12 actually have notes that play (apparently each track in this particular file corresponds to one instrument and sends notes in specific midi channel).

I haven't got time to implement Meta Event parser, so the messages appear a bit cryptic at the moment. Now that I think of it, the player will need a major overhaul once tempo changes get implemented...

Still checking it.

I am getting a RUBY error from time to time [after clicking some functions - Rewind maybe].

The error is in the Midi-File Player module. It says:

NoMethodError: (in method event): undefined method 'scheduleMethod'

note: using FS v3.0.4 Win7 [64]

Question? Should we be able to hear sounds from the included VSTi module ?

oh... that's a bummer... it seems the "scheduleMethod" system was added in later version of FS. Just comment out the line in the code that contains "scheduleMethod" (use ctrl+F to find it). It is not critical to the functionality. It is there to log which notes are currently on, so it may kill them if playback stops (when setting "play" to false or "rewind"). The only downside is, you will have to reset the streams (clear audio prim) to kill the hanging notes...

Note taken... avoid scheduleMethod for backward compatibility...

hmmm ... I understand backward compatibility ... BUT ...

at the version level, I did the upgrade to v3.06 [i think] ... but I had some major issue happen when I tried
to install it as a separate version [having 2 versions available].

Since I had 3.0.4 for such a long time, and had collected and put together important stuff for me ... I just didn't
want to screw things up, or lose things ... so I just stayed with that.

I did read [somewhere] that 2 versions cannot co-exist ... just can't remember where that was, or how to do this without losing stuff.

If anyone could point me to the info again ... Great !

As an aside ... I didn't want to invest further into FS [updates were way to long between], and now the talk of a 64-bit version. THAT would be my interest.

Nonetheless, I like to follow all the threads and postings here, just to stay connected with FS and the 'Gang'.

Tested it on 3.0.6 and it seems working. Also the rewind" feature is very cool. Wondering if there is any way to just extraxt the full midi data out of the file without playing the notes. String format is welcome since it can easily set parmeters of any kind of Ruby based note\step sequencer inside FS. In that way, we can use the file utility as solid midi data extracter insteed of a player

RJHollins wrote:... I had some major issue happen when I tried
to install it as a separate version [having 2 versions available].
I did read [somewhere] that 2 versions cannot co-exist ... just can't remember where that was, or how to do this without losing stuff.
If anyone could point me to the info again ... Great !

MyCo prepared a registry toggle for alpha testers because we had 2 versions installed simultaneously. The registry entry is for the installation path to Flowstone.exe which is normally set when installing FS.

If you install your second version and choose a new folder name such as …\Flowstone xyz you can double click on the appropriate reg file to change the registry entry. When you want to use your original installation just double click on the reg file for it. This way it takes just seconds to switch versions.

You are probably aware that if you right click on the reg file you can edit the path as you wish, so you could have any folder name, like Flowstone306 for example.

I found that this toggling doesn’t affect your toolbox etc. since the user data is stored in your user’s Roaming Appdata path. But it’s always a good idea to back up everything (including the registry) first. You could create a windows restore point first too.

See the attached…

Cheers

Spogg

Thank-you Spogg ! Will definitely check this out.