Regarding X-Box 360 and Wii Primitives

oddson · 11 Dec 2011

You could use the Switch primitives to read whichever source is the one that's active at the moment.

mahavishnuman · 11 Dec 2011

Thank you, Oddson, for the gentle nudge; I have a vague idea of what you're implying, which I'm sure will become clearer once I spend more time with SynthMaker and start structuring the GUI. I'm really only planning the GUI with loose concepts until I finish the processing portion of the design, but I thought it wise to at least ask about external controllers to get a rough idea of what work would lie ahead.

So, to verify that we're on the same page -

When the user opts to use a controller (by means of some button), a default knob (or last knob used) is chosen from within the plug-in (and highlighted for the user to know which one carries focus). The contoller can then be used (possibly through the D-Pad) to move focus (and the highlighted field). A knob maniplated by mouse would steal control and focus from the other controller. This would require:

1. The plug-in keeps track of which knob was last used by means of either mouse or controller; this is where a switch would come in to report which input has most recently changed. When typing "switch" into the search box, I don't see one with more than two inputs; must I construct or code something, or is there a neater or quicker way?

2. The plug-in must handle messages from the controller to change focus and highlight the new knob; I'm thinking an index map (perhaps stored in an array) would allow the plug-in to maintain orientation and know where to jump if up or down were pressed (as moving within a row of knobs would just simply increment/decrement). Any general ideas on a simpler or more elegant solution?

3. Would I be correct in assuming that mouse priority would be satisfied if the circuitry for the first point were constructed properly?

Thanks again for your time and consideration on the topic. I know I'm asking very general questions without offering schematics or insight into the concept itself, but as I said before I'm only in the planning stages for the GUI and I'd rather not expose my work until it has at least some coherency.

oddson · 11 Dec 2011

mahavishnuman wrote: ...When the user opts to use a controller (by means of some button), a default knob (or last knob used) is chosen from within the plug-in (and highlighted for the user to know which one carries focus). The contoller can then be used (possibly through the D-Pad) to move focus (and the highlighted field). A knob maniplated by mouse would steal control and focus from the other controller....

You seem to be suggesting that the control is either/or while I was suggesting it could be both of two controllers that have 'focus' (or more accurately neither!).

I was assuming you'd want to be able to nudge a parameter with a mouse or any other means while still retaining all the existing input from the controller... the problem with a 'focus' model is you can suddenly get all kinds of changes as the focus jumps back and forth between two controllers that are not synchronized between many parameters. In fact some of what follows in your post suggest you're concerned about this too... so to continue...

mahavishnuman wrote: This would require:

1. The plug-in keeps track of which knob was last used by means of either mouse or controller; this is where a switch would come in to report which input has most recently changed. When typing "switch" into the search box, I don't see one with more than two inputs; must I construct or code something, or is there a neater or quicker way?

Switches can be ganged to provide as many inputs as needed (for n inputs you need n-1 switches):

mahavishnuman wrote: 2. The plug-in must handle messages from the controller to change focus and highlight the new knob; I'm thinking an index map (perhaps stored in an array) would allow the plug-in to maintain orientation and know where to jump if up or down were pressed (as moving within a row of knobs would just simply increment/decrement). Any general ideas on a simpler or more elegant solution?

I think the idea of 'focus' in getting in the way again... if focus is only for each parameter you don't need an array to keep track - the switches remember the last update no matter which controller it came from.

mahavishnuman wrote: 3. Would I be correct in assuming that mouse priority would be satisfied if the circuitry for the first point were constructed properly?

No clue what you mean here.

mahavishnuman wrote: Thanks again for your time and consideration on the topic. I know I'm asking very general questions without offering schematics or insight into the concept itself, but as I said before I'm only in the planning stages for the GUI and I'd rather not expose my work until it has at least some coherency.

No problem... it's sometimes a mistake to go too far down the road before you know which road you should be on... On the other hand it wouldn't hurt to do a mock up of a small number of parameters (say for a peak filter with f/q/g) and start getting some first hand experience with the issue instead of waiting until you're trying to sort it out on 100 parameters.

The one issue I did consider when I posted my simple answer is how to retake 'focus' for a single parameter when the mouse choosen value is well off of the controller's current position without jumps. In that case you may want to have it so the new controller only regains control when it approximates the current position of the parameter. Here's a sketch on how that might work with two controls:

mahavishnuman · 11 Dec 2011

Thanks again, although I suppose maybe my terminology is a little off (considering my last serious attempt at programming was with my old Commodore 64, when UI was never preceded by a G). To clarify:

"Focus" as I define it is simply travelling from one area of possible input to the next, just as one might hit the "Tab" key to navigate text boxes in a Windows application. Moving there doesn't change the parameter itself, so there shouldn't be loss of sync; to change a knob's value, for instance, you may either click and drag with a mouse or hold a fire button on a controller and move the joystick. A click or fire button would be necessary to signal intent to change value, and in most cases changes would be relative to the current value.

I imagined that focus would be important mainly in use of a game controller, as from what I can tell there would be no direct way to move the mouse cursor with it (even if there was a way, it would be unwieldy).

When I referred to the "button" that would enable a game controller, I meant only that the button would serve to:

1. Prevent unnecessary GUI objects by disabling the highlight box (which I think would be required as the game controller will not move the mouse pointer), and

2. Prevent accidental control for those whose computers double as DAWs and gaming rigs. If they left the controller connected but didn't intend to use it with the plug-in, they wouldn't want unintentional movement of the controller to interfere with their work.

It wouldn't have to be either/or; the actual value for each parameter would not change without holding a mouse/controller button. The third point may have been my way of answering my own question on this while thinking aloud (and as my thoughts are usually mirky, so it sounds when I think aloud). I was only really asking whether the mouse would have priority; in other words, if the controller is still active but I choose to tweak a parameter with the mouse, the mouse should not be locked out while the controller's "focus" occupies the knob. I assume that, so long as the switches are configured properly, I shouldn't have any problem.

The second issue just deals with how to manage navigation from the controller. Again, since X-Box controllers are two-handed and Wii controllers typically occupy one's dominant hand, it would be a bad idea to require the user to constantly use the mouse in order to control a different knob. Therefore, my thought was the plug-in must have an internal map of sorts to know what knob the user can move to from the current position.

For example, I'm in the bottom-right most knob in the plug-in. If I need to jump to another knob, I can only move up or left. My idea was to use a map so the plug-in can figure this out; my question was whether there might be a better way.

Your .png answered another lurking question that I forgot to answer through experimentation - how to handle Boolean switching. I guessed it would be best done through an integer switch, but in playing around I never remembered to check.

Thanks again. Believe me, I'm tinkering with mini-schematics - mainly trying to familiarize myself with creating GUI, as the actual DSP end seems reasonably intuitive and straght-forward so far. Hopefully my clarification helps, although I think some of what you said did click.

oddson · 12 Dec 2011

yeah... it didn't put 'focus' in single quotes because I didn't know what you meant... only because I was talking about it as a metaphor.

If you just want to switch whether game control is allowed or not something like this should work: Alter the part of a control that allows MIDI input

To also allow your external control -- but only if the global wireless says to.

Then all you need is a wireless transmitter that is TRUE only if the user has activated it in whatever way you want.

I hope I'm getting closer... 😉

mahavishnuman · 19 Dec 2011

Oddson,

Thanks again for your reply. Sorry I haven't responded sooner; due to current lack of audio work in my area I am steadily employed in retail, and well - 'tis the season.

I'm still not sure we're on the same page, but I'm satisfied that some of the information you presented has given me enough of a springboard to find the answers experimentally. I am sure to have more questions soon that will be peppered throughout the forums, and a drowning newbie such as I am glad to have such speedy help.