- This topic has 9 replies, 3 voices, and was last updated 16 years, 4 months ago by
.
-
Posts
-
If we can’t have arbitrary clusters, maybe we could have the concept of PAGE skipping?
This would work the same way as STEP skipping.
While in GRID mode, press and hold the MUT button and select a PAGE. If the page is part of a currently active cluster, it will start blinking red.
Now as the cluster plays, this page will be skipped.
As an alternative we could have a possible PAGE length of zero, the current lowest value for PAGE length is one. This wouldn’t be as nice in a live setting, where "unskipping" a PAGE should be quick and easy.
cheers
ripeQuote:As an alternative we could have a possible PAGE length of zero, the current lowest value for PAGE length is one. This wouldn’t be as nice in a live setting, where "unskipping" a PAGE should be quick and easy.Zero page length sounds like trouble (a looping zero lenth page…:S )
But page skipping sounds very logic. On the other hand I don´t think that Gabriel has said that there can not be arbitrary clusters. I just suspect that there has been other priorities.I think when I spoke to Gabriel about it (arbitrary clusters), he mentioned it would be a fundamental change to the way clusters work and would require some sizable effort.
I agree on the point about zero page length and a race condition… that wouldn’t be good!
cheers
ripeThe story about arbitrary clusters has two sides to it.
The one is about usability. The current implementation is "good" because the state is immediately visible and easy to handle. On the opposite, imagine absolutely arbitrary clustering, across banks and all, and how you would find out what is playing in which order. The idea does not appeal to me, but there sure is a way in the middle and that is why we are here and discuss.
The other side is about implementation effort, which indeed is significant, and will probably have to wait until other things are in place.
Like ..oh yes, SYSEX data compatibility across versions
My original request for arbitrary clusters was for an implementation similar to the current, just removing the side-by-side restriction. I don’t know how desirable it would be to have completely arbitrary clusters across banks, etc!
Here was my diagram regarding a possible implementation of clustering:
cheers
ripePost edited by: ripe, at: 2008/05/16 20:22
Nice graphics!
But what if you have more than one cluster in a bank? How would holding the selector button show them, and more inportantly, differentiate? The individual cluster steps could be mixed (interleaved). The graphic doesn’t cover that, or does it?
Ah, didn’t know. I assumed several clusters were allowed. Time to RTFM again, lol.
In that case, it could work, though not as visual as the current cluster indeed.
Why can’t we have several clusters? :huh:
I assume you mean several clusters in the same row. If so, that goes back to the question of how to visualize them intuitively and directly. Again a usability issue.
I agree with John’s proposal though, in that if you have arbitrary clustering you would have one per row.
Depending on your work mode this tradeoff may or may not be desirable.The way I look at it now it seems harmless to allow for several clusters (in the current sense, joined consecutive pages) in a bank, provided they are separated with ‘blank’ pages. When using the proposed arbitrary clustering within a bank, having more than one cluster is visually almost impossible. Okay, I’ll get back to this when I’ve touched the subject myself.
- You must be logged in to reply to this topic.