Hey guys! I was wondering if there was some sort of “write protection” for patterns. It sounds vague but here a problem I’m having and perhaps a “pattern write lock” might be the solution for it.
Let’s say I’m playing live and I’m on Pattern 5, I do Func + Yes to save pattern to temp, start fiddling with Ctrl-All, I do some sort of “build up”, towards the end of the pattern, I arm pattern 6. Pattern 6 starts to play. When I’m back to pattern 5, my Ctrl-All changes are already there and I need to press Func+No to reset it, but even for a split second, I hear the Ctrl-All tweaked state, and that’s a bit annoying when playing live.
Am I missing something? Is there some sort of “wrlte protection” feature already? If not, do you think it should be implemented?
Don’t have a DT anymore but if the pattern and project are already saved do you need to save “pattern 5” to temp? If you don’t save it to temp will “pattern 5” restore to its permanent saved state the next time it plays?
Nope, the moment you change something it’s “saved” to that particular pattern, therefore when you switch back to pattern 5, the last state is restored, not the default state.
You could copy and paste the Original state of pattern 5 to, say, pattern 7 so that you can alter pattern 5 to bits, switch to 6 then move to 7 and voila… that thing you wanted to happen happens!
also, the thing youre wrapping your mind around right now could be a thing that you appreciate later on. If my patterns reverted to a “saved” state upon re-entry i do NOT think id like that at all…
I suggested a very easy work-around for your situation. let me know what you think
Obviously the workaround you suggested is the first thing that came to my mind, but it’s really bad practice imo. (i’m originally a developer and what you suggest leads to what we call “spaghetti code”, which summons disasters at some point )
Why waste another pattern slot for this? What if I want to have a buildup on Pattern 6 before switching back to Pattern 5? Will I need to waste 1 more pattern slot for this? What if I want to do this stuff in also in another section of the song (let’s say Pattern 8), Will I spend 3 patterns -pehaps even in another Bank- to store default versions? Really inconvenient.
What I’m requesting as a feature is a “toggle” btw (so maybe you can enable on a “live” situation), not a permanent change. So I don’t believe it would harm workflow of anyone.
i wouldnt consider that a “waste” of a pattern slot if it accomplishes something that you want to happen.
you can do that . build pattern 6 up and switch back to pattern 5, whats the problem?
the answer is in your hands.
ive never used more than 8 patterns for one song and the damned thing was like 13 minutes long…
I’m sorry man but your argument is invalid. Being a developer did not stop me from producing music for the last 2 decades. I was a musician long before I learned to code. Didn’t really need to hear “practice using your instrument” from a random person in a thread where I request a practical and valid feature…
argument?
i suggested a valid work-around to solve your problem.
not arguing with you.
a very baked in function, i might add.
cheers.
welcome to the forum!
A workaround is a… workaround. A workaround has a “cost”.
Anyways I don’t really understand the hostility… Is it some sort of cardinal sin to talk about a feature that would possibly make people’s life easier? (apparently I’m not the only one asking for such feature)
DEEPMOSES implied I was “moaning” and suggested I should submit a feature request and move on (I might as well hammer my DT, delete my account and f*king kill myself while I’m there) that did sound a bit “bossy”…
Anyways, you realize your workaround works only “once”, right? Let’s say instead of the “messed up” Pattern 5, I switched to the stored “default” version on Pattern 7. Before switching to the Pattern 6 (let’s say it’s the chorus) I’ll need to do the build up again, this time on Pattern 7. Now it’s also “messed up” and I don’t have a “vanilla” section I’ll return to. So this workaround costs 1 pattern slot per 1 “build up” you have. This is what I meant while throwing the “sphagetti code” analogy.
Obviously spamming Func+No after you arm Pattern 5 so it reverts back to the default state in a split second is a much more convenient workaround, that doesn’t cost you a pattern slot per build up. Even though it doesn’t waste a pattern, it’s super prone to human error and it costs “time” (ties your hands), these are really critical in a “live” scenario.
P.S: A fine, structured piece of code does not have any “duplicates” at all
)