Forum: Wishes and new features

Features you would like to see in VirtualDJ
Sujet Two ideas for the independent pad_pages
Hi!
I love the independent pad_pages!
Great job! Thanks to the developers!
I only have two additional ideas which I think could be useful, depending the interaction with the skin.

The independent pad_pages only make sense if there is more than one controller (with pads) connected at the same time.
At the current version the skin shows the pad_page which is triggered from the controller without independent pad_pages (if I got this right).

So my first idea:
If there is only one controller connected at a time (except the keyboard), independent pad_pages seem kind of senseless.
So it would be nice if the skin could show the pad_pages triggered from this one controller, even if it is set to independent pad_pages.
As soon as a second controller gets connected with or without independent pad_pages this behaviour could be turned off by the software.

My second idea - or lets say a more advanced/combined version of my first idea:
The whole workflow with the independent pad_pages could be "pushed further" if the skin would show the last pad_page that got triggered by any controller.
No matter if the controller is set to independent pad_pages or not.
The skin could show the pad_page that got chosen last, so that the workflow is always the same, for example:
If I choose a new pad_page on 'no-matter-which' controller, I possibly still want to check what my pads do or how they are mapped.
So if I leave the pad_pages on the first controller how they are, I usually know what they are for...
But if I choose a new pad_page on another controller (which has independent pad_pages) I maybe want to see what the pads are doing.
And a quick look on the display is just anchored in every workflow.
And since I'm concentrated on the controller which I'm calling the new pad_pages from, it makes sense to show the last called pad_page to stay in focus and in this whole workflow-thing.

Maybe this could be implemented as an option in the options-menu, so that every user could decide how he likes his workflow.
And idea number 2 would somehow contain idea number 1, so two birds with one stone.

What do you think about that? :)

Posté Tue 07 May 19 @ 4:00 pm
locodogPRO InfinityModeratorMember since 2013
You can do this with direct mapping of your hardware.

Posté Tue 07 May 19 @ 4:28 pm
Ok... so first, thank you for your help, I appreciate it very much... Therefore: sorry if I am somehow criticizing you... I don't mean to offend you or someone else... but... why is here always someone telling me to do this on my own?

I know that I can tell the software to open a pad_page, despite the fact that this would mean to set every device to independent pad_pages and code it into every mapping, to change only the display but not the pad_pages on the connected devices, I find it more important that there are users who want to get access to more features like this or a better workflow and even more important is that not every user is able of coding.
If I wanted to do this for my own, i would.
But I thought this forum is meant to connect, collect and share knowledge and ideas to bring the software to a higher level.
Not for my personal experience, but for all the 10+ million users of this software.



Posté Tue 07 May 19 @ 6:00 pm
AdionPRO InfinityCTOMember since 2006
I'm not sure if the first point is really that useful though.
Wouldn't you typically have one main controller following the decks, and some sort of smaller controller for additional pads?
If you would connect only one, wouldn't it be your main controller anyway?

I can see the use in the second idea. If you use the skin mainly for visual aid, it would indeed make sense to simply see the last pad page there, whichever controller it came from.
I'm wondering if in that case it should be the pad page that was last switched to, or the pad page that was last used. (So just pressing a pad on the other controller would switch the pad page on screen)

Posté Tue 07 May 19 @ 7:06 pm
Hi Adion!

Quote :
I'm not sure if the first point is really that useful though.
Wouldn't you typically have one main controller following the decks, and some sort of smaller controller for additional pads?
If you would connect only one, wouldn't it be your main controller anyway?


I marked some of your text bold, because the first point was exactly meant like this. Maybe I confused you with the connection of a second controller, but it was meant like if there is only one controller connected at a time... in any way it would indeed be the main controller. But as far as I saw, if this one controller is set to independent pad_pages, the skin still behaives Like there is another controller because it does not update the pad_pages on the screen.
So basically if there is only one controller connected the independent pad_page-setting of this controller could be ignored to update the pad_pages on the screen, since there is only one controller.

----------------------------------------

Quote :
I can see the use in the second idea. If you use the skin mainly for visual aid, it would indeed make sense to simply see the last pad page there, whichever controller it came from.
I'm wondering if in that case it should be the pad page that was last switched to, or the pad page that was last used. (So just pressing a pad on the other controller would switch the pad page on screen)


This seems also as a great idea. I not even thought this far :D
Maybe it could be slightly confusing in the first moments, but it seems kind of self explaining after some tries, so people should get used to it fast.
Maybe an option in options-menu could contain both solutions... But I think I like your "full-service"-idea much more, because the skin woukd be always up to date. :)

Posté Wed 08 May 19 @ 4:27 am
AdionPRO InfinityCTOMember since 2006
If you actually only have one controller, and you set it to independent pad pages, you would do this for a reason no?
I can imagine it being useful to use the controller pads independently with the typical default pages that are already written on the controller, and then use the one on screen with keyboard, mouse or touch-screen and use some custom/advanced ones there that perhaps don't need to be accessible as quickly as with a controller.

Posté Wed 08 May 19 @ 5:10 am
Adion wrote :
If you actually only have one controller, and you set it to independent pad pages, you would do this for a reason no?
I can imagine it being useful to use the controller pads independently with the typical default pages that are already written on the controller, and then use the one on screen with keyboard, mouse or touch-screen and use some custom/advanced ones there that perhaps don't need to be accessible as quickly as with a controller.


I tought about this constellation too as I got to that point where the keyboard is also a controller, during writing my first text in this topic.
Yes, what you said makes sense. I just didn't find a useful scenario from my point of view. Maybe someone does, and that's why it could be an extra option in the menu.

But to update the display with every last called pad_page from any controller somehow contains the first idea. So it loses in meaning a bit.
But as you expanded my second idea with yours, the first point gets meaningless anyway.

So i think it sounds like we could have a good solution here, and by adding an option for that every user could decide how he wants work... The function stays the same, but the workflow could be more personalized by the way the skin is updating to the actions on the pads. :)

Posté Wed 08 May 19 @ 6:17 am