Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MIDI MSC #59

Open
offtools opened this issue Jan 20, 2017 · 5 comments
Open

MIDI MSC #59

offtools opened this issue Jan 20, 2017 · 5 comments
Labels
enhancement/request Suggestion for new features or improvements

Comments

@offtools
Copy link
Contributor

offtools commented Jan 20, 2017

Hi,

there was a discussion about MSC in an earlier issue. I want to restart the discussion.
MSC sounds interesting and it is somehow a must for this kind of software ;)

The question is, what commands should be supported on the output side. Which manufacturers should be taken in account, MA, ETC, ...
Should the MSC GO for instance bound to the GO button or extend MIDI Cues to do that.
MSC input could be also very handy.

In short I would like to set MSC onto the TODO list.

offtools

@FrancescoCeruti
Copy link
Owner

Yeah, no harm in adding it to the TODO, it seems quite useful and widely adopted.

Maybe a specific cue for them? The input can be added to the controller (this should support "global" controls in 0.4.3)?

This make me think, can be useful a plugin that allow to create some kind of template (to match messages) to globally control the cues, easily, without the need to setup every cue? Eventually supporting both receiving and sending messages with various protocols (MIDI/MSC/OSC/...).

@FrancescoCeruti FrancescoCeruti added the enhancement/request Suggestion for new features or improvements label Jan 21, 2017
@offtools
Copy link
Contributor Author

Hi,

For Outgoing MSC a own cue type make sense, as the argument size is variable in difference to the standard MIDI messages. As the possibities of MSC and the range of the commands is by around a number of over 50 it makes also sense to put that in an own cuetype.

Asuming global controls means things like controls which are not configured inside a Cue, e.g. Go/Stop/Play in the cuelist. For OSC these global (/lisp/go ...) incoming messages are handled by native OSC callbacks, the rest is forwared to the controls via the fallback callback. A unified interface for that would be useful: so that the user could setup: GO is triggered by Osc message XY and Midi message XZ as it could be done now for the GO keysequence.

@FrancescoCeruti
Copy link
Owner

Asuming global controls means things like controls which are not configured inside a Cue, e.g. Go/Stop/Play in the cuelist. For OSC these global (/lisp/go ...) incoming messages are handled by native OSC callbacks, the rest is forwared to the controls via the fallback callback. A unified interface for that would be useful: so that the user could setup: GO is triggered by Osc message XY and Midi message XZ as it could be done now for the GO keysequence.

Exactly, the idea is to provide it as part of the controller plugin, if it's simple enough, otherwise as a separate plugin.

@aroom
Copy link

aroom commented Jan 27, 2018

hi @offtools, hi @FrancescoCeruti ,

do you have any news about MSC and OSC implantation ?

is there any code that we can already use ?

@FrancescoCeruti
Copy link
Owner

FrancescoCeruti commented Jan 27, 2018

Hi, an OSC plugin has already been merged into the dev branch, but right now the branch might be unusable, there is an MSC pull-request (#68) with an implementation, but I don't remember if it's complete.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement/request Suggestion for new features or improvements
Projects
None yet
Development

No branches or pull requests

3 participants