CTRLR plattform

Home Forums Development Change requests CTRLR plattform

Viewing 1 post (of 1 total)
  • Author
  • #114659
      • Topics: 11
      • Replies: 23
      • Total: 34

      I can feel this program would have a greater impact if the panel editor would be a javascript online project, because it is basicly about transform click events into midi messages “well apart from the VST part.

      Because then people could fill in what messages they knew for certain synths online, and basicly build up a message library for each synth. I like the flashy graphic panels but the ability to just throw out a midimessage from a message list upon the canvas and have a “named” controller is even more exciting.

      Because then one could have people specialised with UI to just build those.
      As i can see there is only three or four parts here, you have the midi in messages on port, that you can chose to send thru that means a control surface “of some kind”. You have the midi output messages “those are specific for each synth” can be a combination of messages to reach a function and set its values.
      So the values can either by set by hardware controller or software “panel” controller surface.
      Now the ideal is for the implementer to know “nothing about the hardware implementation” except for the “messages” needed to reach the function and the scope / range they can be set in.

      That basicly just an option list for each synth, and a link to a software controller withe rang or hardware with range to set value. You simply drag and drop a message to canvas, and control it by events like mouse, keyboard. Or you have “input panels” for controllers and simply link it to the “out message”.

      This way there would be thousands of more panels done, because some people are good read hardware specs and put together message pipes to reach functionality, others are good in design interfaces.

      Actually i’ve been thinking of make this possible for my UMX490 controller to my Korg 364 synth and old Korg SoundLink168RC mixer. Because they have such shitty interfaces. But in the bigger picture i realise it is just two “option lists” holding a “sequense of messages” ->pipe to reach a functionality.
      So in first list there is the controller knobs and buttons in the other the functionality.

      And there between is a simple message translation, and that is the basic for any hardware to edit, or set values, or steer. With javascript having both option lists volume meter and knobs basicly as default. It is just a matter of information collections from specs to see what messages supported “not my strong side”. Put/Pipe them into functionality routes x->y->c to reach oscillatior, reverb, or whatever to set value “where these have a range” defined.

      I can’t see there is more to it so this project really need to migrate to the web, before someone else implement it for the web. So you need the ability to check a message functionality, by basicly write in a message and name it in an option list “steering the hardware” with a connected range if it is an editing message. Although i have not reached any functionality on my SC-7 because there is none i simply assume that reach a functionality is simply a message chain. Followed by a value if it is an editing feature.

      Functionality: Name: Range: Message:”x->-y->z”

      And then you just put that name in option list drag and drop to canvas, and either you steer it with a javascript volume meter and knob. Or link it to a know on your controller keyboard.


    Viewing 1 post (of 1 total)
    • The forum ‘Change requests’ is closed to new topics and replies.
    There is currently 0 users and 59 guests online
    No users are currently active
    Forum Statistics
    Threads: 2,495, Posts: 17,374, Members: 77,605
    Most users ever online was 12 on January 22, 2019 3:47 pm