Midi Ports

[haydxn]

i’ve been building a midi handling class, making use of the various JUCE midi classes, which provides a midi learn function.

however i’m not sure where the best place to place it in a project would be.

should the midi handling be a global thing? or should it live within a component as a member object? or should it actually be inherited into the parent object?

similarly, where should the midiinputcallback class be? at the moment it’s inherited into my MidiHandler class, but this class is not a visible component; if i wanted the callback to update a label on the gui i guess it would be more convenient to have the callback inherited into the parent component instead and send midi messages there (where it can easily use the message to update children components).

i’m just not sure what the safest approach should be.

also, i’m having a few problems with the MidiInput / MidiOutput port openings… sometimes it doesn’t get them, and VC++express says that it’s getting some errors from them. i’m not sure about threads or anything yet, but perhaps it’s something to do with that? they open most of the time, but sometimes when it’s running vc++e shows debug errors such as

First-chance exception at 0x7c90eb74 (ntdll.dll) in MCUTrigger.exe: 0xC0000008: An invalid handle was specified.

if something like midiox is already running then i don’t really get problems. is this thread related? some of the thread exit things say

The thread ‘mmGetCurrentTask’ (0x3b8) has exited with code 1 (0x1).

and i expect that that means an error? (code 0 is normal, right?)

[Steve]

Not sure if this applies but I get first-chance exceptions when I’ve quit my Juce app in the middle of debugging – thereby not letting Juce get a chance to close the MIDI ports. I resort to opening/closing MIDIOx and everything works after that.

[haydxn]

hopefully someone can reply to this (jules?) i won’t start a new thread about it that’d be messy!

i have a midioutput created in my ‘MidiHandler’ class, which gets used by a midilearn class i’ve created. two ‘portselector’ components link to the handler which allow the input and output ports to be selected from those available.

however, i wish for some of my other classes contained in various components to be able to directly send midi messages to the output contained in the midihandler class.

i’d thought about making a new messaging class from the JUCE message bases (so something similar to actionbroadcaster/listener, but specifically for midi messages) so that the midihandler can be a midilistener that will send any messages sent by a midibroadcaster directly to its output port. is this something that is worthwhile? i’d very much like to hear your opinion.

while i’m designing the classes and getting them to work, it is extremely cumbersome to make sure that the objects i want to be able to send messages have a pointer to the output port; it’s only assigned when the program is running, and that means that the midihandler needs to update every other component with the new currently selected midi port pointer… something that is a bitch to do when you’re just trying out ideas.

for now, i’ve simply made a global pointer which gets updated when a port is opened. this saves me the trouble of having to make a pointer updating network for now, as they can directly use this from anywhere. as it’s a port that will be used by the whole program, in “mad person’s theory” it’s quite sensible to have it as a globally accessible pointer. however, understandably “je n’aime pas” having to rely on a global pointer. i guess it’s not SO bad as it wouldn’t compile if it weren’t there, but having classes depend on stuff that may just not exist is a little daunting.

i’d really like to hear your opinion on this jules… perhaps you can give me an idea as to a sensible way to structure the program with regards to midi port access?

at the moment my midi learn system uses ‘targets’ (a base class which can be inherited into any component/class). a target has a virtual function ‘respond(int value)’ which is called by the learner when a learned message is recieved (the target’s pointer is found from a table as 'the right target for this message). a ‘becomeTarget()’ can be called from the object to focus the learner on that object as the destination for the next recieved message; adapting a slider to ‘becomeTarget()’ when it is right clicked means that the next midi message will be automatically mapped to that slider; here, respond() simply sets the value of the slider according to the input midi value.

however i also have a target based class which is to simply generate an output message from a learned input. a table of these targets holds the MCU midi commands, and the learner allows you to map these to input messages - thus when the learned messages are recieved, the command target’s respond() function is called, which should send a message to the selected output port.

hopefully this illustrates my problem?

[jules]

I suppose I’d just create a singleton that keeps the open midi port privately inside it, and exposes methods to send messages to the port. So you’d have a sendMessage() method on your singleton, that passes the message to whatever its current port is, or discards it if no port is open.

Hope that’s what you meant - I only skimmed through your post!

[haydxn]

yes, thank you that’s exactly the kind of thing i needed to hear. sorry for the long post! :hihi:

thanks a bunch for that, this should get much easier now without living in the caveman hackshack