Problem with midi/remote control of Metro from Numerology

[brook]

So I may be missing something here due to my ignorance but here's what I'm trying to do and what's happening instead:

I want to use the triple XY modules in numerology for real time (live) control of softsynth parameters running in metro.

So: Metro is set to record from Num's midi outs, and the remote control window is set (for example) to have CC55 control the filter cutoff and CC56 control the waveshaper of Buzzer, which is running successfuly on track 1 in Metro.

Numerology is set to output the x axis of xy#1 on CC55 and the y axis on CC56 with appropriate scaling.

Here's what happens: as long as Metro is in the foreground, it reads the current value of the xy controller. But if numerology is in the foreground (so I can actually use the controllers), Metro does not AUDIBLY respond to the controllers - it does record the values onto the track, and it picks up the current values the minute I switch back to metro, but there seems to be no way to apply continous control from numerology (and I'm assuming other similar apps) audibly unless Metro is in the foreground, which of course precludes manipulating the controllers from the other program.

On perhaps a related note, I've noticed similar foreground/background mishaps in the past trying to use virtual midi keyboards with Metro.

Help? Or thoughts? I have a feeling I"m just missing something.

Thanks!

-- Brook Hinton

[brook]

A correction - values from the controllers generated while Metro is in the background are NOT recorded by Metro - the sudden "jump" to the current controller values when switching back to Metro is though.

And: using IAC does not help.

[Jerm]

I will look into this but it sounds like the Metro is not getting any processor time when it is in the background.

[Jerm]

...if numerology is in the foreground (so I can actually use the controllers), Metro does not AUDIBLY respond to the controllers -

I do not have numerology so I cannot test with it.

On perhaps a related note, I've noticed similar foreground/background mishaps in the past trying to use virtual midi keyboards with Metro.

This would be helpful. What utility are you using. I just tried MIDIKeys and it seems to work fine (with the exception of 'wait for note' recording mode, which is broken in the current version).

[brook]

I just tried VMKI (Virtual Midi Keyboard) and it worked - the virtual keyboard problems were some time ago so perhaps that's either a resolved issue or I had done something wrong at the time.

I've done some more attempts at isolating exactly how this behaves:

- If a control signals are sent from Numerology (i.e., an XY change running on its own via setting a long glide duration) with Numerology running and Metro in the FOREGROUND, Metro does respond audibly, but does not RECORD the value changes - only the last value is retained in automation.

- Switching back to NUmerology during the above just freezes the value in Metro at whatever it was. Swithching back to Metro causes the value (this is for playback/live, it's not being recorded - see above) to switch instantly to the current value from Numerology.

So if I'm understanding - Metro SHOULD be able to respond in real time, while in the background, to continous control signals generated from another app routed either through that apps own internal midi outputs or IAC, as long as Metro's midi setup and remote control settings are correct???

If so, and if this appears to only be broken with Numerology, I will see what Five12 has to say (which I should probably do at the same time anyway.)

[Jerm]

Metro SHOULD be able to respond in real time, while in the background, to continous control signals generated from another app routed either through that apps own internal midi outputs or IAC, as long as Metro's midi setup and remote control settings are correct

Yes.

[brook]

update after conferring with Numerology's developer on the five12 list:

1. Numerology should be able to control ANY midi aware app that can recieve its input while that app is in the background, and apparently it's one of the primary things people do with it, controlling synths in Reason, Logic, etc - people switch back and forth in performance with no problems. So it's either my setup, or something funky between Numerology and Metro causing the problem.

2. If the XY windows are visible while in the background (Metro in foreground) and manipulated by holding down the command key while moving the mouse or trackpad, it works. Unfortunatley this won't solve most of the issues I have - most of the time I am needing to have one hand on a midi keyboard at the same time.

ANd this is just the start of it - to really do this project as I planned involves controlling large metro sequences with numerology during perofrmance- not just the XY modules, but the control sequencers, clock manipulation etc. So command-moves with Metro in the foreground won't work since I won't even be able to see most of what I'm needing.

This seems simple, but I'm mostly an audio rather than a midi person so it may just be me. But according to what you and James Coker (the numerology person) are saying, it should work just perfectly. And I really really really really really don't want to use the Usual Suspects for this project - I adore both of these pieces of software and want to do the whole audio performance side of this with small/solo developer tools. The only alternative to numerology for this type of control is Plogue, but it would be a huge pain to get it to function in the way I'd need. (I guess there's also Max/MSP but not going there for now...). And I'm stubbornly dedicated to Metro as the sequencer/host side of this.

Next - I"ll try mapping some midi controllers on my synths to metro and see if THEY function with metro in the background as a test. (sadly, hardware controllers aren't really an option for the project).

Don't know if any of this helps so far. Will report after the next test.

Brook Hinton

[brook]

Well that didn't take long. It's definitely not a Numerology problem.

With Metro and Microsoft Word open (to provide a test foreground app to switch to), and just mapping the modulation wheel on my SY77 to control the waveshaping parameter in buzzer on a track in metro, all works fine IF Metro's in the foreground. If it's in the background, the behavior is just exactly the same as described above with Numerology attempting to control Metro via midi - Metro/Buzzer stops responding to the mod wheel of my hardware synth, then jumps to the current value as soon as I switch Metro to the foreground again.

So either something's not working with remote control while Metro is the background app, or something is wrong deep in the bowels of my powerbook. Metro just isn't responding to control messages while in the background period. (It does still respond to notes).

Hoping this is something fixable (or worth fixing),

Brook Hinton

[Jerm]

Hoping this is something fixable (or worth fixing),

Definitely is worth fixing. Let me take a look at this. Thanks for reproducing it without numerology.

I assume you are using Metro 6.2.2. Correct?

[brook]

Yes, 6.2.2. Thanks Jeremy.

[Jerm]

Ok. I understand now. Metro does not currently allow mapping of controllers to EFX parameters while it is in the background however you should be able to map controllers to controllers. This problem will be corrected but I need to know if there are any other remote control events that have the same or similar problems. Please let me know if this is the only problem.

Thanks.

[Jerm]

Fixed in 6.2.3

[brook]

Wow. The legendary amazing Metro support carries on!

Thanks, and I will be on the lookout for similar stuff.