Forum Replies Created
-
Posts
-
it would be nice to have a feature that “renders” the seq offset into the pattern. so like in this case step 13 would become step 1. makes it more intuitive to then work further with it.
@ alien brain:
“how many other step sequencers have a page of cc knobs?”
the zaq is a full sequencer not just a step sequencer.
to answer your question: arturia spark, apc 40, mpc renaissance, trigger finger pro,… all have dedicated control knobs.“why attempt to get bcr behavior from a zaquencer?”
because it fits my musical needs. and obviously also others.“wouldnt you rather see a bunch of improvements to the zaquencer idea and use some other controller as a controller?”
nope“because, i mean, to me, the cc page would be sorta useless unless i could use it in conjunction with zaquencer somehow.”
you can use it with the same or other instruments you are now controlling with the zaq. i dont understand why you dont appreciate the potential in this.
possible uses:
* control attack, decay, pitch and fx send of 8 drumsounds in any software (works probably with some hardware as well)
* control attack, decay, pitch and fx send of 16 drumsounds in any software (works probably with some hardware as well) by using CONTROL mode on 2 tracks.
* control 32 parameters of any soft or hardware synth in your setup – for example the one that you sequence with the zaq on another track.@ christian:
i am struggling a bit with understanding your description, however I think the most flexible (and logical to my brain) implementation of controls would be as a new mode. i could then decide on how many of the 4 tracks i want to use this control mode. and it should of course store the values.isnt a control mode and storing its values very similar to a monophonic chord mode? only differences are it sends cc’s instead of notes and there is no sequenced reading out of its values.
it would probably need some sort of dump command (like the bcr has) so i can send all 32 control values to my software again in case i loaded the zaq before.
i also dont see so many bells and whistles in the original bcr. i think there are many improvements possible which dont need much memory. if you like i will collect ideas for a while and then post them.
it would be great if each CONTROL could be set to CC, NRPN, SYSEX, or… what did I forget? program change!
implementing a parameter lock functionality like DENTEdiSEGA mentioned would of course be a killer feature. i didnt even dare to think that far.
well, thats 1,5 years ago and christian implemented various sequencer features since then.
I think the more you see the zaq as an instrument the more speaks for a bcr/control mode. and there is so much space for ideas to make controlling parameters via dials smarter.any words from the man himself on this?
i know. thats why we want more.
yes please +1000.
i imagine a third mode called CONTROL that, in its most basic form, works like the original BCR.
here’s an example of what could be done with it:
track1: drum mode
track2: control mode – i could map 8*4 controls to the first 8 drum voices. or 16*2 to all 16. if the control mode had a shift function to provide 64 CCs i could use 16*4 controls. I can do the same now with a 2nd BCR and 2 presets of course. But it would just be a more intuitive workflow and make the Zaquencer a more self-contained instrument.
track3: chord mode
track4: control mode – controlling parameters of the instruments played by track3and there would be much space to improve the usefulness of 32 CC beyond just sending 0-127:
* reduce the resolution (and spread it equally over the full encoder range) so that it can be conveniently used to control a function with only a few choices. e.g. selecting the oscillator waveform/filtermode/modulation source in a synth.thanks for your answers, christian. i am pretty happy with the BCR hardware, so for me it wouldn’t be about a sturdier or smaller device. I also agree that the LED encoders are the killer feature of the BCRs. I suggested this because I had the impression you hit already the ceiling in terms of feature-squeezing into the existing flash rom. as long as there is still space it’s for sure the safer thing for you to go with existing hardware.
however….
competition: is always there and no reason to not consider a new project. if any micro company in this field has little to fear from that it’s zaqaudio I think.
price: although i prefer to pay 200 than 400 euro for a similar device I would very much prefer to support a small company than a big company that produces in big factories (no matter if in europe or asia).
investment: a successful crowdfunding campaign would take this burden from you. producing (only?) kits with a network of “trusted builders” around it would make the warranty challenges manageable and, as a side effect, even put (a good part of) the manufacturing into passionate, skilled hands. i am aware that there is still more than enough industrial production involved on the component-level anyway.i am fading into off-topic fields now. maybe these thoughts help you with some long-term decisions in the future…
very cool!
just out of curiosity I would love to hear a bit about that, too!
“sequence offset” is your friend (manual p.15)
it’s at least in stock at both schneidersladen and thomann in germany right now. i have a small but growing euro setup so i would find something to do for the 4 note channels. but your objection regarding the cc’s then being only 128 cv steps makes me put my plan into question. thanks for the input!
@zaq: i understand your concerns. i think every user needs to understand that these hardware limitations in regards to memory are simply there. this actually seems to mean that any progress in features can only be made by cutting off other features and that this is nothing you can influence (significantly). so, as long as you still offer the current version of the zaquencer i don’t really see a problem. zaq 1.1 runs well and bugfree (?). if some people need 192 patterns so be it. many others (like me) would probably call 24 patterns plenty and 48 pattern even massive, and would rather see certain refinements in the sequencing possibilities added to future versions.
thanks for all the explanations, zaq. i knew you crammed the memory but i didn’t expect you crammed it that tight, wow!
i overlooked that drum mode is not velocity sensitive otherwise i would have already had the suspicion that there is no space anymore. i was assuming it uses the full 7bit so it would have only be 4 more bits for the individual midi channels. hmm…ok i will think about something for the one last bit you are offering
let me hi-jack this thread with another – hopefully related – question: the zaquencer offers 192 patterns, right? this sounds like a LOT of memory to me! my question is: if you would cut this down to spare space – is this memory you could use otherwise, for example to implement new features? or are these memories unrelated to each other?
i wrote “it will be like alpha/beta on steroids” so i am obviously aware of alpha/beta.
my proposal is to increase the number of controller lanes (from 2 to 18 per track) by introducing a new mode, which is technically almost there (because, as i wrote, the value pairs which are now formatted to note commands in DRUM mode would simply need to be formatted as continuous controllers). so it won’t “break” the concept.
the bottleneck you describe doesn’t exist because the functionality doesn’t exist yet. you are correct that right now each track sends to only one midi channel. to use the full power of the proposed CONTROL mode it would be necessary to add the possibility for the user to define the midi channel individually per controller lane. this is -technically- as simple as the functionality to define different midi notes in DRUM mode right now.
@rempesm: memory shouldnt be a problem as literally the only difference to DRUM mode is that the number pairs produced by the BCR dials get formatted as [cc number, value] instead of [note, velocity]. all within the same 7 bit range.
@fabi: although a 2nd zaquencer probably never hurts you would get very far with just the 4 tracks you have now:
track 1: 16 drum tracks
track 2 + 3: monophonic/chord sequence
track 4: 16 tracks of sequenced parameter modulationsand then there would be still 4×2 more cc’s!