Some help improving TouchOSC


(Tumulte) #1

Hi,

I try to use the touchOSC and I can tell you it’s the best device one can use to control renoise efficiently (especially now you can find an ipad for the price of a midi hardware)

YET, there are some frustrating stuffs I’d like to improve… but I can’t wrap my head around Duplex (and I’m supposed to be a programmer.

Here is the current layout

8326 touchosc_ipad_config.png

Here is the improved layout :

8327 touchosc_ipad_config.jpg

Some priority modifications :

  • Removing all the right column…which is reserved to some very specific usage

  • Add a solo row…

  • Add a post level, post pan shortcut for each track

  • Get some place by showing few less device parameters (or maybe side by side)

Some very cool stuffs… might be hard tho

  • add track and effects names (even it it’s just the first 8 letters)

  • add a page with all levels and pan (not shown)

  • add a piano page

So… yeah… I’m willing to do all that, but I just manage to break duplex. Would someone want to help me make this new stuff ?


(danoise) #2

I guess you already wrapped your head around how configurations and mappings and applications interact with each other.

Note that the mappings were added on a “need to have” basis, they’re basically all being put to use in one or more of the bundled configurations. So much of this is a question of tweaking or extending applications in order to expose additional mappings -

take the track names, for instance. You’d have to obtain these from somewhere - e.g. the Mixer application or by creating a new application from scratch … both approaches could be a valuable experience in Duplex hacking.

The piano, well, you’d just have to make room for it somehow :slight_smile: I decided to go with a compact, all-in-one layout for this particular layout but as the “iPhone” layout demonstrates you can have multiple pages in TouchOSC.

Happy hacking! And I’d be happy to help a bit out from the sideline, of course.


(Tumulte) #3

Good news, I’ve finally got to understand that thing and make it work. Got a mixer and solos.

Indeed, there’s no built-in functions for naming… I’d love to fine a way to make this work some day !


(Tumulte) #4

For the mixer tracks, I try to indicate visually on which page a user is. I’ve came up with several ideas :

- creating 4 mixer groups of 16 and split them accross 4 osc pages.

- having some page number displayed (like 2/3)

- having buttons to jumb from page to page like [1][2][3][4] rather than just prev/next.

I’d be ok to hard limit the number of available tracks to 32 if it allowed a better visualisation of where you are.

Apparently, none of these are possible out of the box, right ?

Relevant answer below :


(Tumulte) #5

I guess you already wrapped your head around how configurations and mappings and applications interact with each other.

Note that the mappings were added on a “need to have” basis, they’re basically all being put to use in one or more of the bundled configurations. So much of this is a question of tweaking or extending applications in order to expose additional mappings -

take the track names, for instance. You’d have to obtain these from somewhere - e.g. the Mixer application or by creating a new application from scratch … both approaches could be a valuable experience in Duplex hacking.

The piano, well, you’d just have to make room for it somehow :slight_smile: I decided to go with a compact, all-in-one layout for this particular layout but as the “iPhone” layout demonstrates you can have multiple pages in TouchOSC.

Happy hacking! And I’d be happy to help a bit out from the sideline, of course.

Alright, that’s close to perfection now.

However it’s really hard to get it working without track name, and sadly I can’t manage to figure out how to do something like that behaves like device parameters.

Do you think it’d be possible to add a " track_names" thingy available ?

(and maybe a " device_names" as well" ?)

Roughly : something that behaves exactly like param_names, but for tracks and devices :slight_smile:

With the new ipad and the old ones dropping in price, you’d get the perfect controller renoise has always sorta lacked.

I can build the UI… but I’d need a hand on the hacking side if it’s possible

Please :slight_smile:

(here’s the WiP of the second page, more to come !)

8332 Capture.PNG


(Tumulte) #6

Lil’ bump here.

I’m very eager to deliver this tool to the community :slight_smile: Anyone who’s figured out a way to display name or give me any hint is very welcomed


(danoise) #7

Anyone who’s figured out a way to display name or give me any hint is very welcomed

There are several duplex applications dealing with tracks. One is the Mixer, another one the TrackSelector. So I guess you’ll have to figure out which one you’ll be relying on for information about track names (from the screenshot, my guess is the TrackSelector…)

Oncethe extra mappings are added to the application, any configuration could make use of it.


(Tumulte) #8

Thanks for the answer :slight_smile:

You mean I need to add a track_names method to Application/TrackSelector.lua, right ?

However it’d take me quite a while to figure the script… can I turn to a more experienced user to add the method ? Or must I rely on myself and do a pull request ?


(danoise) #9

it’d take me quite a while to figure the script… can I turn to a more experienced user to add the method ? Or must I rely on myself and do a pull request ?

I’m currently packing my bag for the holidays, so I will definitely not be of much assistance for the next few days.

But a pull request would be an awesome way to contribute, no matter who is doing the typing :slight_smile:

If you’re really looking to do this yourself (or just get familiar with the principles), I’d take a look at the Effect application

Just follow where “param_names” is specified, and you’ll see that the mappings are updated (“set_text” method) as a result of attaching to effect device parameters.

The same principle would apply to the track selector - whenever tracks change, update the track name mappings.