krevis / midiapps Goto Github PK

If the user has an older MIDI driver installed, it may force the MIDIServer into 32-bit mode. Since MIDI Monitor's spy driver is no longer compiled for 32-bit, spying just doesn't work in that case.

(I hope it's still possible to build the driver for 32-bit...)

IIRC we can now embed the HexFiend editor into other apps -- that would be far easier than writing our own hex editor.

If you size/position a window, new windows should use that size and/or position.

Recently I was at a hackathon where the WiFi did not support a VPN
connection back to my company's file servers. Instead of starting up,
SysEx Librarian produced a massive sequence of error dialogs, one for each
of my remote sysex files that could not be accessed as it was on an
inaccessible network drive. In the end I had to find and wipe the settings
just to start the application.

Why were we trying to resolve the aliases to the individual files?

It just confuses people and makes them think something is broken, which usually isn't the case.

Program numbers should be displayed to the user in the range 1-128, even though internally they are 0-127. Most devices and apps use 1-128.

Perhaps add a preference like MainStage does:
https://support.apple.com/kb/PH13676?locale=en_US&viewlocale=en_US

tried a few files and I cant get it to load anything. Im on OS X 10.10.5

Time to do this again. Need to add manufacturers to SnoizeMIDI/ManufacturerNames.plist.
For example Mackie is 00 00 66 which isn't in the list.

A sysex file can contain one or more messages.
We should be able to choose one or more of the messages to send, but not all of them.

Would be nice to organize your list of sysex files by folders, categories, etc. At least allow folders to be imported and retained in the UI.

Would be nice to be able to do this from the keyboard.

Allow it to be resized somehow.

Start MIDI Monitor by opening a document. A new untitled window also appears, but shouldn't.

(Reported & reproduced on 10.8.3.)

Turns out that NSNotificationQueue is potentially really buggy. We should use something else.

See the 10.6 Foundation release notes (if you can find them), or:
http://mikeash.com/pyblog/friday-qa-2010-01-08-nsnotificationqueue.html

Like sysex.

Less blinky.

When starting Midi Monitor on the new Mac OS X Lion (10.7) there will be an error with the following text:

MIDI Monitor tried to install a MIDI driver in "Library/Audio/MIDI Drivers" in your your home folder, but it failed. (Do the privileges >allow write access?)

For now, MIDI Monitor will not be able to spy on the output of other MIDI applications, but all other features will still work.

Any suggestions?

Hi Kurt,

thanks for the SnoizeMIDI framework! Unfortunately there's not much documentation about its API.

I'm looking for the absolute minimal setup to capture midi messages on all available interfaces. IMHO it should be the code below, but it's not working. takeMIDImessages is never called.

Any help on this is greatly appreciated!

#import <SnoizeMIDI/SnoizeMIDI.h>


@interface MidiController : NSObject <SMMessageDestination>
{
    SMPortInputStream *inputStream;
}

@end

@implementation MidiController


- (id)init;
{
    inputStream = [[SMPortInputStream alloc] init];
    [inputStream setMessageDestination:self];
    [self addEndpointsToInputStream:[SMSourceEndpoint sourceEndpoints]];

    return self;
}


- (void)addEndpointsToInputStream:(NSArray *)endpoints;
{
    unsigned int endpointIndex, endpointCount;

    endpointCount = (unsigned int)[endpoints count];
    for (endpointIndex = 0; endpointIndex < endpointCount; endpointIndex++)
        [inputStream addEndpoint:[endpoints objectAtIndex:endpointIndex]];
}

//
// SMMessageDestination protocol
//

- (void)takeMIDIMessages:(NSArray *)messagesToTake;
{
    NSLog(@"Midi Message received.");
}

@end

Suggested in email:
"a setting that 'monitors all inputs' - but dynamically adjusts: ie when a new midi interface becomes available (either plugging in a device, or the creation of a virtual interface) for that to be automatically monitored"

So a window would be set to monitor all MIDI sources, and as more are added, they'd automatically get checked.

This would make sense as the default setting -- it's what most people want, most of the time.

It's possible to use the preferences to set the library folder to a directory that isn't writable. When the app starts the next time, it will refuse to launch because of this.

• Check the permissions before allowing the folder to change
• Don't refuse to launch, just let it go until it's time to create a sysex file

Graham Hinton asks:

There seems to be a blindspot in SysEx Librarian in that it assumes that a SysEx dump is manually initiated.
Could you make it send out a SysEx dump request message (which would have to be defined somehow) and then catch the reply?

Not too hard technically, but I'm not sure what the UI/workflow should look like.

See screenshot from Graham Hinton 8/14/07.

Should be able to export the events from a MIDI Monitor window to a Standard MIDI file, with timing included.

Sometimes people have MIDI devices which send sysex at the wrong time, interfering with the sysex they really want to receive. Should add a way to choose which ports to listen to.

When I launch MIDI Monitor after its latest update (now it is 1.3.2), I see this error message:

There is an old version of MIDI Monitor's driver installed, but it could not be removed. To fix this, remove the old driver. (It is probably "Library/Audio/MIDI Drivers/MIDI Monitor.plugin" in your home folder.)

For now, MIDI Monitor will not be able to spy on the output of other MIDI applications, but all other features will still work.

But there are no Library/Audio/MIDI Drivers/MIDI Monitor.plugin file :(

Reported on 10.8.3:
"Ask to save when a changed window is closed" is NOT checked, but it still asks anyway.

Haven't been able to reproduce.

Perhaps it only happens with some combination of settings in the System Preferences, General pane, "Ask to keep changes when closing documents" and "Close windows when quitting an application"? Just a guess.

Would make things easier to read.

I tried adding this, but cant seem to get it to link (Its been a while since Ive used Xcode though)

If we receive e.g. a 3-byte MIDI controller message B0 10 07 in three separate MIDIPackets, currently we only show Invalid messages for "10" and "07". This makes it look like MIDI running status is being used, which isn't the case. We should see an Invalid message for B0 as well.

Hello, I'm currently trying to compile by myself MIDI Monitor.plugin but "mine" isn't working whereas the one that comes with MIDI Monitor.app does.

What I'm doing :
I compile SnoizeMIDISpy by pressing "play", the build is successfull for MIDI Monitor.plugin.
Then I copy MIDI Monitor.plugin to /Users/Username/Library/Audio/MIDI Drivers (replacing the original installed by downloaded app) or even to /Libary/Audio/Midi Drivers (and deleting the other in users folder).
I restart MIDIServer by running "sudo killall MIDIServer"
I start Audio and MIDI Configuration to be sure that MIDIServer is running.
Then I start MIDI Monitor.app that tells me it can't connect to its driver.
And that's true, when I go to Activity Monitor -> MidiServer (double click) -> Opened Files and Ports ... MIDI Monitor is no more in the list ... the driver loading seems to have failed.

Note : when I compile myself the driver has a size of 46kB but the original do have a size of 72kB, clearly they are not the same !

So my question is : is there something special to do to compile driver from sources ? I'm on Mac OS 10.9.5 and running XCode 6.1. What am I doing wrong ?

Thank you by advance

1. In Preferences > Sources, check "New windows will use these sources": "MIDI Sources" and "Spy on output to destinations".
2. Also check "Automatically open window for new sources".
3. Add a new MIDI port -- plug in a device, or turn on network or IAC

Expected: New window has spying turned on for the new source
Actual: Spying is not turned on for the new source.

Most of the time nobody cares, but maybe in "expert mode" we can show which is which.

Some users don't want the extra stuff (byte offset, text), just the hex bytes. Add some way to show only those things, nothing else.

(Apparently REAPER makes it difficult or useless to directly add .syx files -- the best alternative is to export to .mid and then you can at least see the individual sysex events in the file)

MIDI Show Control (MSC) messages are a subset of sysex. We could parse them and display them better than we do now.

When we import a SMF (.midi) file, we drop the timing information. This can lead to the sysex transmission failing, if the receiving device needed those delays.

(Case in point: update for a Kurzweil SP2X)

If there were significant delays between the sysex messages in the original file, we should warn the user about what is going on.

Suggestion from a user:

Now I have to:

1. click Record One in SysEx Librarian
2. go to my synth
3. send the sysex from the synth
4. go back to the computer
5. change the name of the recorded sysex (in Finder or in SysEx Librarian which involves menu diving)
6. click Record One
7. go back to synth
   and so on

It would be much easier if I could record one separate sysex, the SysEx Librarian would ask for the name and after entering the name it would automatically turn into recording next separate sysex and so on. I have cordless computer keyboard so I could do it all from the synth.

It could be even easier if the naming was automatic - for some of the synths the preset name is in the sysex. Maybe it could be an option to set the exact hex position of the preset name in the sysex to make it name the recorded sysexes automatically.

Yet - when I open a new window (without closing the app) - everything comes good again.
It's an out there edge case - but I'm seeing it happen sooner in a different use case.

I'm not on the latest code base - but do you have any idea what is the source of this?
It's like the vvmidimanager / nodes or core midi has died - the c inboard myMIDIReadProc stops processing data.
void myMIDIReadProc(const MIDIPacketList *pktlist, void *refCon, void *connRefCon)

I've tried calling MIDIRestart(); to re-kick start things but it doesn't help.
OSStatus status = MIDIRestart();

In SEL, Open a "contents" window, then click on the split view divider. It instantly collapses down to 0 height, and can't be moved afterwards.

(OS X 10.8.3)

We've got the room, we can show a little bit of the sysex data.

Might be nice to have different views in different windows.

If you rename a file in the Finder, then go back to SysEx Librarian, it doesn't immediately show the new name. Make this quicker.

Eyes-free troubleshooting!

Should build for 64 bit when running on 10.5 (10.6?) or later.

• Spy driver should be 64-bit on 10.6. The 64-bit slice should link against CoreMIDI.framework, not CoreMIDIServer.framework. Also note the need to import CoreMIDI/MIDIDriver.h not CoreMIDIServer/MIDIDriver.h when building against the 10.6 SDK.
• Fix other 64-bit unclean issues.

Certain broken MIDI interfaces like the Alesis USB-MIDI cannot send more than 128 bytes of sysex at a time. Instead of using the built-in MIDISendSysex() function, write my own that has a user-selectable block size. (Need to find one of these interfaces to test with, too.)

For instance, filter just note-ons but not note-offs.

Add a pref to increase the size of the text in source lists and/or the MIDI events list.

Allow showing just the 3 hex bytes of MIDI (e.g. B0 for event on channel 1)

I had to write a custom tool to set the auto-open bit on the disk image, but that was around 2001; there must be a better way by now.

I've got several midi controllers that I use, and change up pretty often. Whenever i plug in a new device (or unplug and replug), I have midi monitor open a new window, as that is very helpful to me. Doing so, however, will automatically enable Clock and Active Sense again, which is a real burden since both are sent several times each second. I constantly find myself toggling open the Filter section and unchecking Clock and Active Sense, then clearing the historical data.

Normally, if people want a way to start the app with some settings, I tell them to save a document and then reopen it later. However that doesn't work in the above scenario, since MIDI Monitor just opens a new window on its own. Add some way to specify the default filter and other settings in the new window.

Hi Kurt,

I upgraded a couple of my systems to El Capitan GM the other day - and have some major beach ball regression in my http://komposer.io app. It was all working so sweet in Yosemite.
I was thinking of chipping in to help with some ARC conversion.
What are your thoughts? Did you try El Capitan? I'll send you an invite to my app.

JP