Hi Sébastien,
yes I'm aware of that. In fact I plan to reserve some time to see how to
fit the new widget to Shade. LateNight and Deere are not a problem. In
fact, my mock-ups are actually modifications to the Deere skin, and it
works well with its minimum size.
Thank you for your reminder.
2016-
Hi Daniel, Ferran and all the others,
a grid layout is a nice idea, but keep in mind that we have users with a
smaller resolution and we need to keep the default skin usable at such
lowres.
Hope you will find a way to add that button grid without increasing the
minimum skin resolution.
regard
Nice to see we have similar points of view.
About the grid layout I have to say I actually like it, supposing my
proposal is chosen I'll ask to the community which layout they prefer and
implement the one that has more support. I can do this while starting to
develop the code changes, which don't
Hi Ferran,
Yes, orphan cue point is it. I must have miss read it, since we already
have this feature in the cue properties tab.
A position and a hot cue number, where the later can be 0 = orphan.
From this point of view your have proposed (1. from my mail below) a
Skin integrated "Hot-Cue" wi
Okay I think now I understand you.
I think what you mean is the same thing that I called "orphan cue points
support" in the proposal.
In the current proposal, a cue point is always tied to a hot cue. When the
hot cue is cleared, the cue point is deleted rather than simply unassigned.
This means th
Hi Ferran,
Your current proposal already works for me.
My ideas came up when thinking about a slick controller intergeneration.
After our discussion I am not sure if we need it at all, including the
button grid.
It can be probably overdone or hard to handle.
But lets explain my original idea
2016-03-22 17:44 GMT+01:00 Be :
> Another idea: the status of the cue list edit mode could be a CO that is
> accessible by controller scripts. Although I think in most cases it would
> be easiest to do most editing of cue points with a mouse, some users may
> want to do that with a controller.
Y
On 03/22/2016 11:18 AM, Ferran Pujol Camins wrote:
> 2016-03-22 16:59 GMT+01:00 Be mailto:b...@gmx.com>>:
>
> 4. I think cues should be able to be dragged and dropped on the
> overview as well as the detail waveform. Perhaps this should only
> work while the cue list is in edit mode t
Another idea: the status of the cue list edit mode could be a CO that is
accessible by controller scripts. Although I think in most cases it
would be easiest to do most editing of cue points with a mouse, some
users may want to do that with a controller.
On 03/22/2016 06:19 AM, Ferran Pujol Cam
2016-03-22 16:59 GMT+01:00 Be :
> 1. Cue colors: How to represent these? HTML/CSS style RGB codes? Integers
> mapped to specific colors? I think it would make sense to use RGB codes in
> the backend for maximum flexibility in the future but only present the
> options for a handful of specific colo
This is turning into a nice proposal :) Some comments and questions for
this new draft:
1. Cue colors: How to represent these? HTML/CSS style RGB codes?
Integers mapped to specific colors? I think it would make sense to use
RGB codes in the backend for maximum flexibility in the future but only
2016-03-22 16:14 GMT+01:00 Daniel Schürmann :
> IMHO it is not required to reflect the exactly the controller layout.
> It was only my thought about how to reflect a static button grid with
> probably multi layers and labels on the controller in your GUI.
So would a 2x4 (2 rows 4 buttons per row
Hi Ferran,
IMHO it is not required to reflect the exactly the controller layout.
It was only my thought about how to reflect a static button grid with
probably multi layers and labels on the controller in your GUI.
If I got it right, the first four Cue-points are tied to the hot cues.
If a user w
Hey Daniel,
Good point, a cue grid would better fit current controllers. There are some
complications:
Different controllers have different have different button layouts. Yours
is 2x2, a MidiFighter or Kontrol F1 is 4x4 and DDJ-RZ is 2x4. Furthermore,
if a User splits a 4x4 controller between two
Hi Ferran,
the new hot cue list looks really nice.
I am just worrying if this will meet the design of recent DJ controllers.
On My RMX 2, I can switch four button per deck to be loop or hotcue
buttons.
Idea (not sure if good):
A button Grid view of the Cue widget, that represents the Hot-Cue COs
On 3/16/2016 3:28 PM, Daniel Schürmann wrote:
>
> * Recall loop cues:
> IMHO DJSally jump mode requires, that the jump happens on cue button
> press and not after release.
> If you distinguish, the activate mode by a long press, you can't jump
> mediately, which is probably required to mix beat s
You made some interesting observations, so long mail :) :
2016-03-16 21:28 GMT+01:00 Daniel Schürmann :
> * Recall loop cues:
> IMHO DJSally jump mode requires, that the jump happens on cue button press
> and not after release.
> If you distinguish, the activate mode by a long press, you can't
Hi Ferran,
thank you for your real nice proposal.
Here some unsorted comments:
* nice Idea using personas for the use cases
* Recall loop cues:
IMHO DJSally jump mode requires, that the jump happens on cue button
press and not after release.
If you distinguish, the activate mode by a long press
Hi Ferran, this looks like a great start.
My biggest concern is requiring another window to be opened for the
fully featured cue point editor. I forsee a few issues with this. First,
it would require duplicating a lot of design and functionality from the
main window/skins. It would also present
19 matches
Mail list logo
