Midi UDF

[ptrex]

Indeed, DJ Controller manufactures just use (and abuse) the MIDI protocol 😉

Makes it really fun doing MIDI mapping 🤪

Lucky we have the MIDI Udf to help out !

When I have some time available, I will see how to fit in the Peace Equalizer app and the MIDI interface 👍

[PeterVerbeek]

Good luck coding 😀 And I let you and Matty know here if someone uses a controller which doesn't work with Peace. Might give some info for us all to use.

[kut0]

Thank you JAPP, that is very kind of you.

[MattyD]

Hi All -

New Release: Version 1.5.

Theres been a MASSIVE update to the helpfiles, so I'm hoping they should pass as a half decent reference now.
Just be aware the chm files may require "unblocking", as they'll likely get tagged as being "from the internet".

Right click the file > properties > Unblock and apply.

Apart from the documentation, notable changes are:

- Support for 3D Audio Controllers.
- Builtin routine for a midi panic button
- Active sensing functionality for output devices.
- midi_ReadMsg & _midi_SendMsg can work with short messages in a variety of formats (Thanks to ptrex)
- Window message registration has been moved to _midi_Startup (Thanks to Peter)

And a bunch more stuff that was fixed that you can find in the helpfile

[PeterVerbeek]

Just great Matty I'll look into it and integrate it in the next Peace version. The moving of the Window message registration to _midi_Startup seems logical. Thanks. And the chms look very nice, very clean. Great work!

[MattyD]

Hi all,

This may be a bit premature, but here is release 1.6.

SCITE integration:
- The helpfile can be brought up with the f1 key when on a _midi_* or _midiAPI_* funcation. Based on the fantastic work of @water .
- Alternate data streams will be stripped when the helpfile is installed to localappdata. This fixes the "unblock file" problem detailed previously.

API:
- Fixed alignment issue with the midihdr tag when compiling as x64.
(the [MM_]MOM_POSITIONCB callback can now correctly locate midi events in a buffer.)

UDF:
- Fixed input buffers not being unprepared before disposal when closing devices.
*** EXPEREMENTAL ***
- Output devices are now opened as streaming devices.
- Added ability to record and playback midi messages.
- Added ability to write and playback standard midi files.
- Added a mechanism for recieving "cue" and "marker" meta events during playback.
- Added ability to modify playback tempo

Be aware that the experimental features are still very early in development, and implementation is likely change drastically down the track!
If anyone is looking for a ealier version of the project, you'll find all previous releases on the sourceforge page.

Happy coding,

Matt

[MattyD]

Just a quick one.

I've just found that sending sysex messages has broken with the last release.
Despite what MS says, it seems you can't use _midi_OutLongMsg with stream handles! ("not supported" errors a-plenty).

There's a good number of functions in the UDF that rely on this, so I would suggest sticking with 1.5 for now.

[MattyD]

Hi folks,

Quick announcement about the band-aid release for 1.6.

V1.6.1:

Script breaking:
- A streaming device handle must be explicitly be requested with _midi_OpenOutput for sequence playback. (new parameter- req. for experimental functions)

Non-script breaking:
- Output devices are no longer opened as streaming devices by default. (reverted behaviour which fixes a multitude of functions)
- Fixed cases where _midi_GetOutputName & _midi_GetInputName were returning False instead of a blank string on failure.

[MattyD]

Hi all, here is release 1.7 of the UDF

The main focus of this release was to bring in some MSC support, which is mainly used with lighting consoles.
MSC can also (potentially) control things like fireworks, and flys/trusses etc. So in the unlikely event anyone is trying to do that, dont! (i.e. read the disclaimer in the helpfile)

Changelog:

- Added some Midi Show Control (MSC) support
- Fixed issue where _midi_CloseOutput failed to close non-stream handles.
- Fixed example scripts for sequence functions.
- Updated reference list links in the helpfile. The midi.org site has been updated, which broke hyperlinks.
- Modified internals for _midi_PackSize

[ptrex]

Hi MattyD,

I am not familiar with MSC (yet). 

Looked at the protol on the internet and looks interesting !

https://help2.malighting.com/Page/grandMA2/remote_control_msc/en/3.3

I have Dj controller that support DMX Lighting. Not sure if this protoco is compatible ...

https://support.numark.com/en/support/solutions/articles/69000797886-how-to-set-up-and-sync-engine-lighting-with-dmx-lights

Anyhow I will dig into this a bit more.

[MattyD]

yeah all good

so DMX is the standard way of controlling lights/fog machines etc, which is usually handled by a lighting console. Typically you'd pre-program a bunch of scenes/cues etc into a cuelist for a show. So in a nutshell, MSC gives you away to navigate those.

Not to cast a downer on things, but I'd be pretty surprised to find a DJ kit that supports MSC. I think it'd more likely generate DMX traffic triggered by pulses in the music.

happy  to be proven wrong though!

[Fritterandwaste]

Hi MattyD

Firstly, thanks for your efforts in the Midi arena, they are very welcome.

I am interested in using AutoIt to send Midi messages to an app on the same machine. That app is "Guitar Rig 6" (GR6)  - which simulates guitar amplifiers and effects. So, for example, I currently use a Behriinger pedal board that sends midi signals via a USB port to Gr6 but I'dlike to be able to do so using AutoIt if possible.

In order for GR6 to process midi signals from the pedal board, I need to change its settings to assign the pedal board as it's input device from a drop down menu of available connected devices. Is there a way, using your UDF, that I could somehow make GR6 aware of an AutoIT script genereated "device" such that it would appear in the dropdown list of connected devices and therefore allow me to send midi messages to it?

Many thanks    

[MattyD]

You are very welcome

Yeah, this should be acheivable. What you're probably looking for is a midi loopback driver.  I've just downloaded this one and it seems to be working ok. I've no idea what the latency is like though - hopefully it'll be ok.

Let me know how you get on!

[Fritterandwaste]

Thank you very much. That's taken me quite a few steps forward and it successfully registers throughput from messages sent using your routines. The GR6 software also recognises  the device I "created" using loopMidi so I connected GR6 to that device to receive its incoming messages. My only problem now is that GR6 does not appear to be receiving the messages. If loopMidi is receiving them do I have to create a second device in LoopMidi and somehow redirect the incoming message to that device, then connect GR6 to the second device?

I could, of course, just be doing something dumb! 🙂

[Fritterandwaste]

Actually I think my problems are now resolved. Thank you once again.