Quick Sign In:  

Forum: Wishes and new features

Topic: Two ideas for the independent pad_pages

This topic is old and might contain outdated or incorrect information.

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? :)
 

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

Posted 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.


 

Posted 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)
 

Posted 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. :)
 

Posted 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.
 

Posted 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. :)
 

Posted Wed 08 May 19 @ 6:17 am
Any news around here, adion? :)
 

Posted Thu 25 Jul 19 @ 4:34 pm
NicotuxHome userMember since 2014
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?[/quote"
You are right.
but it seems pad pages as view as restricted to controller related audio stuffs

andy-chiles wrote :
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.

Of course yes some scenarios may exist:
Independent pad page can be usefull with one controller - or none or any other quantities - in other cases : no deck/dynamic deck/All decks related controls for things like mic & samplers effects, and master video effects i.e.: ZvideoControl, Slid3R, AutoVideoFX, dmx, ColorFX, VideoFX, MicSampler... don't need to be deck dependent even some may be used as deck dependent as well

[quote=andy-chiles]adding an option for that every user could decide how he wants work...

is always a good idea in software - but for politics
 

Posted Thu 25 Jul 19 @ 5:21 pm
I like this idea. The secondary controller is usually flying blindly. I find myself having to switch pad pages manually every time I want to use the secondary controller for pad performance. I read in a post above that it can be done by scripting. I would appreciate if anyone can give an example of how to make the pad pages change in the main skin from the secondary controller.
 

Posted Thu 25 Jul 19 @ 8:26 pm
I don't get why it should be confusing, or difficult, or any problem in any way to add a small but lovely switch for a soooooooo massively large part of the program...

Sorry, but if we have to discuss every all so small idea, then the good things that are happening on this page somewhen will disappear.
 

Posted Thu 25 Jul 19 @ 9:16 pm
Just wanted to throw my 2 cents in on this. A quick caveat first. I haven't seen a software that really does additional pad controllers in the way I would expect them to function so at the very least the current implementation of independent pad modes is better than RBDJ for instance.

What I'm trying to accomplish personally with this is to have essentially an 8 button pad section that represents my DDJ-1000 and a 16 button pad section that represents my DDJ-XP2. This way I could view what all 24 (8 for the 1000, 16 for the xp2) pads are assigned to, as well as what all 8 pad modes (per controller) are assigned to quickly with on the fly editing capabilities.

After much searching through the skins customization and controller customization options I know it's possible to hard code this type of functionality and use pad mode buttons to trigger panel group switching however this would completely circumvent the very well established, thought out, and easy to use pad_page functionality that already exists. So why reinvent the wheel you know?

If I'm missing something and this is possible another way it's really the only thing holding me back from getting the pro license. Currently using RBDJ works perfectly the way I would expect it to when using just the DDJ-1000, and so does VDJ, however when adding my XP2 both programs currently have limitations in the visual cue department.

 

Posted Mon 18 May 20 @ 8:34 pm


(Old topics and forums are automatically closed)