I haven’t published it yet as loads of it is not fully hooked up in the sysex in terms of the patch request, and I didn’t want to confuse people with a work in progress, if that’s against the etiquette?
If it’ OK to publish them as work in progress though I’ll do so.
Here’s the current project file:
I will have a go at it this weekend and report back. Thank you!
Here’s a quick and dirty version of the XY vector control. It is on the page 6 (Performance). It is implemented using the new feature of v3.6.0 - the custom controls. The XY pad actually controls the MIDI parameters cc #16 and cc #17. ie. all controls linked to these should reflect all changes made to them from anywhere.
Look and feel, dimensions, and behaviour can be adjusted in Lua. I tried to be quite descriptive there in the Lua code.
Note, it is plan to add controls such as XY pad to a standard library of controls. Consider this as one of the first steps there. Plus, this provides the preset creator full flexibility to adjust the control.
My god, it’s wonderful… wipes tear away
Hi. Wondering if you got around to trying the XY touch pad on the preset yet. I still haven’t messed around with your TG 33 editor yet, as I’ve been insanely busy with work and what limited time I have for music has just been committed to working out ideas I already have rather than testing equipment/midi etc.
Martin, what is allowed in that touch callback?
I know if i try to do too much (like print the x and y), it locks up.
What i was looking to do was use the screen touch instead of a double tap on the encoder. But, i will need to map the touch point into various control bounds.
I can do all that, just need to know what is allowed inside the callback
@oldgearguy, there are no real restrictions. As with all callbacks, it should not run long blocking calls. Long actions should be broken down to smaller bits.
The lock up is actually caused by the long touch (with no finger movement). It is a gesture to open the detail window - I will prevent that for now as there is no real support for custom detail windows yet anyways.
Ok, great. It seems to me a touch on screen on a control can be more reliably parsed as a toggle rather than the encoder double tap. I will try to play with that a bit this weekend
Hi Martin, do you have a link for the preset with the touch pad yet? I took a bit of a break from Electra One stuff to actually flesh out some ideas for tracks that had been sitting on the back burner for longer than I would have liked, but tomorrow is a “just experiment with gear” kind of day.
Hey. Having a great time with this preset. However, the vector control CC sliders don’t seem to be working. I sent LFO’s to CC’s 16 and 17 with my sequencer and that worked fine, so I believe it is something with the preset
In the current state it’s basically just Stu’s preset, with two extra sliders, but I’ve begun hooking up the patch request and response behind the scenes, so the main pages are pretty much as they were.
Like yourself I have work and other bits so progress is slow, I’ve also got an order of play now, which is the Kasser DAFM (a Yamaha 2612 synth, now finished and published), the Yamaha PSS480 (currently writing all the Lua, as it’s simple enough to help me learn it compared or many synths) then after that I’ll hit TG33 again I think.
As you can see I’m a Yamaha fan 
Keep us posted! Would be amazing to get the xy touch pad and 2 op fm voices ironed out. Thanks!
The risky call to open the detail window of custom controls is prevented in v3.6.1. There are no restrictions on what you can do in the touch callback. Please take a look at LcdTouchEvent documentation - the touch callback supports multi-touch. Each touch point has its own id.
excellent news there.
So if I wanted to have multiple controls around a screen be touch-enabled I would just define a touchCallback() and assign it to the controls I want to watch?
Then inside the callback I will have the touch event and the control ID associated with it so I can distinguish one control from another.
I am looking to have the callback trigger a small series of calls:
some math,
value = control:getValue(“value”),
currentDefault = value:getDefault()
value:setDefault(newDefault)
(the goal for me is to toggle between two modes of data display for that control).
yup, that should work. Please take a look at the modified TG33 preset. It has XY pad that is used to calculate and set values of two CC faders. (on the Performance page)
I’m away from the studio for the day but can’t wait to try this!!
I will.
One other thing I noticed that might be eventually useful –
there was an assert in the example:
– Preset compatibility check
assert(
controller.isRequired(MODEL_MK2, “3.6.0”),
“Version 3.6.0 or higher is required”
)
Question (well, maybe 2 questions) - is there a nice way we can use thecontroller.isRequired() to enable or disable certain extra features?
Also - if there’s a preset that can do more on the mk II but by default it would overflow memory on the Mk I, can the additional mk II data and functions be part of the preset, but only conditionally loaded?
So you only have to edit changes in one preset, but it can run on both (with some functionality removed).
That’s ace to see it in action! I’ll pull this one to continue linking up patch request etc once I’m done on the PSS 480! 
I’ve finished the Yamaha PSS480 patch now, which is entirely Lua virtual controls so I’m now a lot more comfortable with that aspect of things.
I’ll need a little break from the heavy technical stuff before diving back into the TG33, as I’ll end up burning myself out on it otherwise 
but will let you all know when I’m back on this one.
I’d say it depends. If the difference was in objects that you allocate dynamically then answer is yes. If it was about actual Lua code, the only way would be to split preset’s Lua into several modules. The controller can do that already. The support for managing that in the web editor is missing. It is on the long run todo list.