Midi Beat Clock Remote

[hirada]

So, for those, who do not want to use the Remote 7 breakoutbox, but are otherwise worried, that their shiny ethernet port will start to rust, I'd suggest a remote control that allows for sending start, pause, stop (pause with reset) commands and setting of the BPM of the internal clock.

I do guess/hope, the internal clock is running all the time anyway, now we just need a comfortable way to adjust it and tell the connected gear to actually start working. Or stop thereof.

To me this (probably) would make using the MRCC as a clock master a way more alluring. Now probably, because I do not have this device as of yet, to be fair.

[Edit]: Maybe this could even be archived with a specialised midi device connected to one of the USB host ports, that is talking to the MRCC? Instead of Ethernet.

Sending start/stop from a remote machine is no magic, we just need to make shure it is talking to the MRCC and not directly to the out ports, just the setting of the BPM could be a little trickier, but nrpn should be able to do the magic.

So we would need to be able, probably via menu, that in this case a certain usb port is routed to the MRCC. And therefore the buttons have no effect.

In the end, I guess, I prefer the ethernet solution.

[oldgearguy]

Wouldn't it be easier to just change the OS to either support actual MIDI clock incoming Start/Stop messages or implement support via MIDI CC messages?

[hirada]

Well, in the end, it is of course up to the devs to decide, which way would be the easiest to implement this, if it gets implemented at all at some point in time. The basic idea is just a remote control, that simply works.

And ethernet has the advantage of not wasting a port. But how they will communicate has to be decided by the people who actually know the internals.

Now one could expand on this concept by making this remote controll also be the master of start/stop if an external clock is chosen. Using this function is a macro that simply filters all start/stop commands from all input ports and replaces it with it's own.

And the final step would be, that on that remote control one could choose the origin of the clock. Ports 1-6 or interally, while still always mainting the controll of the transport commands. This would be an additional macro that automagically also filters the clocks on all other input ports, without the need to menu dive. Allows for quick change of the clock source.

Which outputs recieve the clock is of course a subject to their respective filtering rules, no change here.

So we'd have play/pause and stop on that control for transport, one knob for BPM setting (of course only applicable if internal clock is chosen as source) and another knob for selecting the source of the clock (internal, port 1-6, usb..). Could also be dedicated buttons.

That would be rather nifty, wouldn't it?

[oldgearguy]

Well, in the end, it is of course up to the devs to decide, which way would be the easiest to implement this, if it gets implemented at all at some point in time. The basic idea is just a remote control, that simply works.

And ethernet has the advantage of not wasting a port. But how they will communicate has to be decided by the people who actually know the internals.

Now one could expand on this concept by making this remote control also be the master of start/stop if an external clock is chosen. Using this function is a macro that simply filters all start/stop commands from all input ports and replaces it with it's own.

And the final step would be, that on that remote control one could choose the origin of the clock. Ports 1-6 or internally, while still always maintaining the control of the transport commands. This would be an additional macro that automagically also filters the clocks on all other input ports, without the need to menu dive. Allows for quick change of the clock source.

Which outputs receive the clock is of course a subject to their respective filtering rules, no change here.

So we'd have play/pause and stop on that control for transport, one knob for BPM setting (of course only applicable if internal clock is chosen as source) and another knob for selecting the source of the clock (internal, port 1-6, usb..). Could also be dedicated buttons.

That would be rather nifty, wouldn't it?

Those are some good ideas for sure, but for those of us using that port for connecting two MRCCs or for additional outputs (or additional inputs soon, maybe), this would yet one more box wanting to use that connection.

To be honest, I love the MRCC and respect the Conductive Labs devs, but I would not want the MRCC to be my master clock.  Why?  Well, once you have it be the master clock, you're going to naturally want to be able to set/adjust delay times for each connection/port, want to be able to do things like swing the timing on a port or have some ports run half time/double time, etc.  IMHO the MRCC interface is not designed for that level of detailed editing and (just a guess here), the amount of free code space to support all that extra functionality may not be available and the extra storage required to save all that in memory may also be an issue.

Having the MRCC cleanly sync up to existing MIDI clock messages is a more natural fit with far less overhead in both code complexity and data use.  Plus you can use any device as you master clock or even have multiple clocks available to drive the MRCC all using the currently available MIDI/USB/PC ports.

Again, we don't have a view for the internal development schedule/plans and we really don't know what is possible to accomplish via the external port or in the OS, so at this point it's all just suggestions for them to ponder.

[hirada]

But MRCC already can act as a master clock, so really no change here. All I have been suggesting, is to make that functionality more accessible for those who actually do want to use that feature.
Instead of menu diving to set BPM and transport and setting up filter rules, simply use a seperate device. Just some buttons that act as macros for the already available functionality, that is just hidden somewhere in the menu right now. Nothing more.

And that, according to my idea, would even work, if the MRCC is synced to an external clock, but may still take the role of transport control. And if that is not desired as well, just don't buy it (in case it would ever be available for purchase, that is).

And if someone prefers to use the eth port otherwise, thats perfectly fine. Again, it should be thought of as an option, a hardware addon, not an integral part. Like the remote 7 is.
Conducitice labs are surely knowing the market better than I do, but, since this is a feature request subforum, I thought, I'd give it a go. And CL is of course free to dismiss it. No offense taken.