Alternative front-end for touch screen?

[han-so1omon]

Any interest in creating a more touch friendly version? It could be useful on a Raspi touch as an Ingen plugin.

[georgkrause]

@han-so1omon Do you have any precise hint what would need to be changed to be more touch sensitive? I sometimes use my X201t touchscreen to interact with luppp which works okayish for the clips. Its hard to use the knobs, but i think thats more an issue of avtk.

@harryhaaren is working on ctrla-integration at the moment, maybe its possible to create an OSC-Interface and build an external, touch friendly GUI. There might be also the possibility to tweak the current UI to improve touch interactions, if you tell us some points to do.

But i dont want to rise your hope on this. There is not much developer time and there is a lot of stuff to do. This project is moving slowly and currently there is nobody working on a plugin version, there are no plans to do so.

[han-so1omon]

Unfortunately not that familiar with backend track management, but here are some suggestions. Some may already exist.

The goal is to minimize accidental clicks and bring attention to important functions so that they are usable in real time.

One to two tracks on screen at a time. Track selection panel to bring different tracks to the foreground. Global pause. Global loop length quantization-sync (cutting length or changing speed). Notification bar for tracks currently playing.

In my mind this definitely needs an LV2 plug-in version. Perhaps if someone can diagram out how to do that I'll give it a shot.

[georgkrause]

One to two tracks on screen at a time.

This would prohibit the user to do actions on multiple tracks at the same time, eg start 5 clips together. Do you really want this? This would also destroy the overview over the hole session, because you cant view the state of all clips in at once.

Global pause.

Already there, use Play/Stop-Button

Global loop length quantization-sync (cutting length or changing speed).

I dont get what is the actual request here. The length of the clips is already "quantized" (multiples of one bar). What do you want to achieve?

Notification bar for tracks currently playing.

Its not just important what tracks are playing, but also which clips. Thats why its useful to see all at once.

Don't get me wrong, i dont want to block your ideas quite from the beginning. I am pretty thankful someone gives some input, but we need some actual usecases because we want to create a coherent workflow, not "just" single features.

To keep things in order, i would like to dicuss the lv2-plugin request in another issue: #234

[han-so1omon]

Your feedback is good. I haven't played around with Luppp too much, so it's entirely possible that my issues aren't that relevant.

The goal is to make tracking easier to manage with fingers. Fingers are fat and imprecise, so small buttons are not very good. Click-and-drag and fast-click/multi-click type operations are good for fingers. Fingers can be all over the screen very quickly compared to a mouse. I will diagram something up later.

Here is an example in text:

---

A bunch of large square representing different loops. Click a square to highlight a loop. In a corner it will display an image of loop properties (e.g. length, volume, frequency range maybe). This image could go under a similar image of the current loop.

There is only one big green play button in the corner that will play all highlighted loops. There are two pause buttons. One for highlighted loops and another for all loops.

In another tab is loop recording. Loop recording has only a few buttons: record, playback, delete. As a track is recorded it makes the characteristic loop image. Clicking on the loop image highlights it. Clicking below the loop image cuts it at that point. The separate parts can be highlighted. Drag the loop by highlighting and moving. Delete the loop by highlighting and pressing delete button. Loop length should also be able to somehow be specified with a transparent border overlaying the loop image.

---

That's just one idea. I think it will be better for touch, but maybe not.

[georgkrause]

I will diagram something up later.

Yes, please :)

A bunch of large square representing different loops. Click a square to highlight a loop. In a corner it will display an image of loop properties (e.g. length, volume, frequency range maybe). This image could go under a similar image of the current loop.

This will take away the big benefit, that you can control everything with one click. At the moment, you can launch, stop and record by simply clicking on a clip. Your proposal would mean, that you mean 2 clicks for each clip interaction, i dont like that idea.

There is only one big green play button in the corner that will play all highlighted loops. There are two pause buttons. One for highlighted loops and another for all loops.

At the moment you can "play" several clips by simply clicking on them. You can pause clips, by clicking on them while playing. There is no way to stop all playing clips, exepct launching an empty scene or stopping the transport.

In another tab is loop recording. Loop recording has only a few buttons: record, playback, delete. As a track is recorded it makes the characteristic loop image. Clicking on the loop image highlights it.

Seperating recording from playing makes no sense. We would destroy this pretty easy behavior to launch/stop/record by one single interaction in dependence to the current state. This is live incredible, i dont want to remove this, too.

Clicking below the loop image cuts it at that point. The separate parts can be highlighted. Drag the loop by highlighting and moving. Delete the loop by highlighting and pressing delete button. Loop length should also be able to somehow be specified with a transparent border overlaying the loop image.

Live cutting and moving is indeed kind of interesting but might be hard to implement and is out of my current scope. But i would support a Pull Request with that feature if it integrates nice in the current workflow.

In general, i understand the need for better touch support. But changing the hole UI and removing nice features for this, wont get my support. Sorry for this one. But the last decision is at @harryhaaren

We can get bigger clip buttons by reducing the number of tracks/scenes:

There might be also the need to get better handling of faders/knobs but this might be an issue of atvk (another openav project).

[georgkrause]

I would like to discuss this with your, on irc or xmpp maybe?

[han-so1omon]

I would be glad to discuss perhaps this Friday. It's been quite a busy week. Let me know a time and other details and I will have a diagram prepared. Understand that I am not well-versed in many of the subtleties of GUI development, so it will be helpful to explain those things if it seems like I'm off base.

[georgkrause]

@han-so1omon which time would be okay for you? for me everything before 3pm (Germany) would be fine.

[georgkrause]

@han-so1omon will be in IRC in about one hour again, maybe you want to join me

[han-so1omon]

I had a string of 24hr work days in a row. I'll prep a diagram tomorrow and will be free from then on. US EST, but free around the clock generally.

[georgkrause]

@han-so1omon dont stress yourself, take the time you need and if you have something done we could discuss on any channel.

[han-so1omon]

I have diagrammed something up that we can discuss as well as prepared some simple questions to get started. Probably will be free for the rest of the week to discuss.

[georgkrause]

Please post this here, so everyone can look at it. I would like to do this kind of offhand, just ping me here if you have time. I am most time when i have time to chat on irc and you could join me then.

[han-so1omon]

The inspiration for this is a common audio production board. Simple additions are shown to take advantage of the tablet's ability to drastically shift visual context very quickly by simple hand motions.

luppp_diagram.pdf

[georgkrause]

@han-so1omon i am on IRC now for the next few hours.

[georgkrause]

Since you don't seem to join me on IRC, i will say some points here (always corresponding to your points)

1. Already implemented, simply click on an empty Clip to record, length quantized to bars. Deleting is also possible with Midi, not so much on the GUI. Could be improved, if you have a proposal for the workflow, let us know. By choosing where to record, you also assign the recoding to a clip.

2. This seems to be a lot of work. I dont know what workflows do you want to create by combining loops. There is already an ticket for clip retriggering and skipping: #156

3. You already can interact with multiple clips at one specific point in time. You also can see the state of all clips everytime. Drag and Drop is not possible right now, but this should be implemented in AVTK.

We wont replace the current behavior on clips by your proposal. At the moment you can record a clip by simply clicking on it. I dont see any advantage in choosing a clip and select the action in another stop. Usually, there is also one action possible. If the clip is empty, you can record. If the clip is loaded, you can play. If the clip is playing, you can stop it.

Also, i don't see why you should need the waveforms displayed. Why do you need this information? The space in Luppp is pretty well planned and there is nothing left for a waveform. Also this needs work. Unless you explain why someone would need this, i dont feel okay with spending work on that.

To answer your questions:

1. In the Buffer of a Looperclip instance.
2. There are functions called. Recording works by copying data into the buffer. Loading/Adding works the same. Deleting clears the buffer. Modifying is not implemented.
3. I cannot answer this question.
4. I dont know if i got this question right, but we use an internal one which stores to be computed events in a ringbuffer.

[georgkrause]

Since here is nothing new and most of the proposed points wont be implemented, i am closing this.