Wishlist: arbitrary text areas in skins, accessible by controller scripts

Bug #1123979 reported by rob
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mixxx
Confirmed
Wishlist
Unassigned

Bug Description

...I'm just starting to think about developing skins and haven't really started to play around yet, so it's possible this functionality already exists - but it doesn't seem to be covered in the skin wiki page, so I assume it's not implemented yet.

It seems to me that it would be useful to have the capability to put text areas on skins that could be filled with arbitrary text from a controller script. Would be helpful for debugging, but also for implementing indicators and data for special script functionality that isn't tied to a specific control.

For example: I'm working on a scratch controller script. One of the features of this script is that it allows the user to change engine.scratchEnable parameters with the controller knobs. It would be great to output the parameter values to a little text box somewhere visible on the skin, so that when the user finds settings that work well, she can see what the settings are, so they can be duplicated. Lots of other applications come to mind too.

It also seems that you can't define arbitrary on/off, knob, fader, etc. controls to appear on skins, and address those with a controller script... That would be useful as well. But of the two, I'd like to see the text area implemented first since that would have broader applications.

Tags: controllers
Changed in mixxx:
status: New → Confirmed
importance: Undecided → Wishlist
Revision history for this message
Daniel Schürmann (daschuer) wrote :

Hi Rob,

Thank you for posting your good Idea.

This sounds like an interesting project making Mixxx the most flexible DJ software :-)
There are many task to do for it:
* Allow creating control object from scrips
* find a place in the GUI (Bug #986704)
* Text Widgets
* ...

Revision history for this message
Sean M. Pappalardo (pegasus-renegadetech) wrote :

Creating MixxxControls (currently known as ControlObjects) from scripts, then adding them to skins would be the most flexible option compatible with the rest of Mixxx. But toggling them on and off (and making them appear when the skin didn't originally provision them) are items to be addressed by a new skinning engine that's been in discussion for awhile now.

Revision history for this message
RJ Skerry-Ryan (rryan) wrote : Re: [Bug 1123979] Re: Wishlist: arbitrary text areas in skins, accessible by controller scripts

Actually hiding/showing an arbitrary text area using a ControlObject is
easy to do with the current skin system and that is in fact how the
show/hide sampler/VC/mic section is implemented in skins. You can already
make fixed text in the skin using a <Text> section. So that is all possible
today.

But I think Rob is actually talking about the controller script being able
to change the text. For that we will need strings in Controls which is not
going to be there until we rewrite the control system to be better (harder
faster stronger).

On Wed, Feb 13, 2013 at 8:15 AM, Sean M. Pappalardo <
<email address hidden>> wrote:

> Creating MixxxControls (currently known as ControlObjects) from scripts,
> then adding them to skins would be the most flexible option compatible
> with the rest of Mixxx. But toggling them on and off (and making them
> appear when the skin didn't originally provision them) are items to be
> addressed by a new skinning engine that's been in discussion for awhile
> now.
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/1123979
>
> Title:
> Wishlist: arbitrary text areas in skins, accessible by controller
> scripts
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1123979/+subscriptions
>

Revision history for this message
rob (another-rob) wrote :

Yeah, I mean allowing the controller script to update the text. And it occurred to me after I posted this that it was probably not going to be possible given the fact that one of you guys mentioned that the control functions only take number types as parameters. Wishlist, anyway.

Incidentally, seems Launchpad is showing 1.11 is showing as having been released - congratulations and thanks.

Revision history for this message
rob (another-rob) wrote :

Oh wait... never mind on the "released" thing - looks like it's "expected in 5 hours" now. So, congratulations in five hours, or whenever.

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

I wish! We hope to release it within a week though.

Revision history for this message
Chloé AVRILLON (chloe-avrillon) wrote :

We are in Mixx 1.12beta now, and this functionality could be sooooooooooooo usefull.
It is a strong wish :
https://bugs.launchpad.net/mixxx/+bug/1505766

Revision history for this message
Daniel Schürmann (daschuer) wrote :

What for?

I know you have already given some hints in Bug #1505766 but a generic solution for that will be unlikely part of 1.12 or 1.13

But maybe it is possible to solve some of your requirements with the existing skin features or by special solution for each of it.
So please line out the features that matter most to you.

A GUI Mockup/Scribble that shows the generic text area would be also be useful.
I am currently hesitant if a generic solution will look nice and if it really fits all your needs.

Revision history for this message
Chloé AVRILLON (chloe-avrillon) wrote :

For the skins I agree that many things already exist : fixed text+indicators can do the trick provided the fact we can attach to them some new controls.

We need to give some visual feedback in a way or other to the deejay and very often, the leds of the controller is not enough. (fader start for instance )

May be we could provide an array of let say 32 (power of 2) true/false free states controls doing nothing in mixxx other than reflecting their state in a skin.

Skins side : everything exist (fixed text, icons that can reflect change when attached to a control )
It will be up to the mapper to adapt a skin to his mapping.
Scripting side :
engine. setValue(group,"free1",true);
engine. connectControl(group,"free21");

Xml side :
‹key›free17‹/key›

Do you think it wil be hard to implement this in the Mixxx code?

Example of use :
Display witch loop size is selected even if it is not activated.
Display wich effect chain is selected for modification (it is not easy to find 8 buttons on a controller to code the "next effect/previous effect" for instance and when mapping we often do the economy of buttons : 1 or 2 to select the effect rack (need visual feedback here) and then 1 or 2 buttons to cycle and choose the effect of the "current" effect rack)
- indicator to tell if we are in loop roll mode/normal loop mode.
- etc....

Revision history for this message
Daniel Schürmann (daschuer) wrote :

Once we have place for that, on the screen, the back-end will be relative easy to implement.

I any case it is a good start.

However, the usability of such a field may be not as good as expected. Maybe we could think about a skin element that is provided by the midi script. Or try to move the features entirely to the Mixxx C++ domain.

For the loop control region, we may provide a second alternative GUI that fits better to your controller.
The controller can select which region is displayed.

The same may be possible for the effect region.

Revision history for this message
Chloé AVRILLON (chloe-avrillon) wrote :

I mean it's up to the mapper to adapt skins to their mapping.
Personnally I am ready to do that for my mapping as an example in order to provide a skin adapted to the reloop beatpad.

For instance, what it is not so usefull for this category of controller is all the display of the effect chain.
My mapping, just change the effect1 of each effect rack (not enough button for the 2nd or 3rd effect).

In shade there is lenty of room, and Deere is just perfect with the effect chains collapsed to add a few little icons like quantize.

It will be pretty much the same for a dj-ssb or a Mixtrack.

For the loop part, I was thinking that a skin icon that can display let say 8 different states could be very usefull.
On 1 display "1/8"
On 2 display "1/4"
On 3 display "1/2"
...
On 8 display "16"

What to display is up to the skin designer.

"However, the usability of such a field may be not as good as expected", true, if the skin wich is made specific for a particular mapping is used for another mapping. Other else, oh no, I don't think that some extra visual feedback will be more harmfull than a lack of feedback.

Another example I have implemented in the Mixtrack pro 3 that could benefit of a visual feedback is the possibility to shift lock the deck.

traditionally, as long as you hold the shift button , you are in shift state, or for some mapping, shift is a toggle.

In the mapping I provide, shift is a holder. If you double press quickly the shift button , the shift is locked as a toggle button : best of both world.
Now, on the mixtrack, the shift button does not provide a led feedback to remeber if you are in shift state or not and rather than using another led of another button for this is .... baaaaaaddd.
Have the hability to provide a skin with an icon attaced to the, let's say, "free1" control is enough to provide a visual feedback and propose the user to activate or deactivate the shift lock from the software.
I think it is pretty straight, easy, versatile enough (and thus elegant) to consider for many many new enhanced experience in Mixxx without creating any new skin widget. It is very generic !
It is a direct interface between skins and javascript that do not affect the C++ so much other that create an array, and the handling of this array (set true/false an element, and provide the connect control string (free1, free2, ..., free32)

tags: added: controllers
removed: wishlist
Revision history for this message
Swiftb0y (swiftb0y) wrote :

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/6913

lock status: Metadata changes locked and limited to project staff
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.