Forum Replies Created
-
Posts
-
Hi Juan,
I appreciate the idea, but I must also say I´m not certain if and when it can be realized.
It´s not so much a problem of flash this time but more of interface, how to squeeze it in and make everything work together etc. I had thought this through in the original development and there were quite a bit of details to address. It is solvable, but still would be quite a programming effort. At this time there are many other more pressing topics for the Zaquencer. As with every feature request I kindly ask not to expect anything and be happy about every additional feature I manage to add on top of what is existing now (also see the sticky in the FR forum).Now brace yourself for a really spaced-out idea
(not saying this is a substitute for your request, but this works with the as-is-state and maybe it will help you anyway)
If you can spare a CC track and the Midi Input, you could experiment with placing a CC message at the end of each pattern which will trigger the loading of the new pattern by sending the CC back into the Midi input. For this “Trigger Enbl” must be turned on in the Global menu. I haven´t tried this, but theoretically it should work.
This is not having a screen to a globally arrange, but each pattern would hold the info which next pattern to trigger. More like a linked list if you are familiar with C programming.
Let me know if you are interested in this and we can dig more into the specifics together.Hi dissocioo,
first, please check out the “getting started” here:
https://zaqaudio.com/forums/topic/sticky-usage-getting-startedThis is a step-by-step instruction.
The drum mode description starts at the middle of the page (To create a drum track…)If you have any more questions after reading this, please post back here and I´ll be happy to answer them!
hehe nice
Hi guys,
thanks for all your suggestions! I really appreciate it, with combined brainpower we get more refined ideas.Regarding this topic, I´m not decided on how to proceed yet though.
My plan is to first keep working on the SysEx export and if I can get that to work maybe it´ll be an easier decision. 192 patterns were decided at the beginning when it looked like export was impossible (which it might still be – I´ll see very soon).Working on the flash pattern arrangement is a hassle, also for the user, as everytime a new parameter is added or changed everyone has to do a flash init, which is deleting all your old patterns.
Also, to rework the flash would be quite time-consuming and I have to see if that time can be funded/justified.
Thanks for reporting back, steve! There don´t seem to be many maschine users here…
And: yay! for more youtube videos
I can see your´s alien, but not simon´s (only when I click the link – nice setup btw
).I think for a picture to be properly embedded here you have to provide an img link that points to the actual picture (with .jpg or similar at the end) and not a site displaying the pic.
Cheers!
Well yes, the flash memory is enough for 192 patterns.
If that number would be cut, it would mean more memory for the individual pattern.
The only thing that makes sense from the internal architecture etc. is to cut it down to 96 patterns, which would mean double the memory per pattern.The thing is it´s hard to take away existing features. In another thread people were wondering the same thing with the patterns and the were voices against cutting the number of patterns, where the 192 patterns were a deciding feature.
Hi Fabi,
thanks for sharing your idea!I understand where you´re coming from, but I must say I also prefer to have the Zaquencer operate independently on default.
Like you wrote, master and slave already share the complete Midi Clock (Start/Stop and BPM through clock pulses).
If you think about it, there are not really so many settings that would make sense to share. Scale (Base) and Note display would come to mind as you wrote, maybe Quantization but that´s pretty much it. So it´s not really a lot of work to enter these manually for the user and would still be some work to implement it in the software.I´ve just tested this here and can´t reproduce the behaviour you´re describing.
Here the reset button has it´s normal function, even on external clock, like it should be.Reset is affected by the quantization, maybe the quantization was set too high?
I´m afraid this is not possible at the moment.
When recording midi data, the notes are always quantized to the step grid.
You can use Note Delay afterwards to shift them around in time.Can you see the logo? Embedding with the “img” button seems to work for non-FB pics…
I´ve checked the prefs and there is no option for pics.
I´ve disabled vids because embedding didn´t work and like this we cn at least see the links.
Maybe it´s because it´s linking to Facebook? Lemme try something:
While I understand that this would be great, unfortunately it is not at all as easy as pure suggested. Please let me explain: a controller message is made up of 3 bytes. So is a note message, so I understand where your thinking is coming from, pure. The thing is that there is a lot of trickery already involved to have the drum mode in there at all. You see, while for every drum hit there is a full midi note being generated, the way it´s stored internally is reduced to the absolute minimum information needed.
So the note number + midi channel always comes from the Global menu settings. and then we don´t use the 7 bit for velocity, but only one bit for on/off of the drum note (using velocity 127). So actually for every step we use only one bit of memory per drum instrument, or 16 bits for all 16 drum instruments.
To generate a CC message is much more expensive in flash memory. Even if you´d move midi channel nr and controller number to flash (like it is now), you´d still need all 7 bits for each generated CC value. Even for a regular track we only afford that much for pitch, velocity and Alpha/Beta parameters, where it´s definitely needed. The memory for all the other params (mute, delay, length etc) is already reduced to their value ranges.
So for 16 additional CC messages we´d need additional 16 x 6 bits (we already have one) in flash per step! or 16 x 6 x 32 bits = 3072 bits for 32 steps. And there is no possibility of squeezing that amount in at all. As I wrote in the ratcheting thread, with a lot of effort it might be possible to gain one additional bit per step.Please let me know if this is still unclear and I´ll be happy to delve in deeper.
Cheers!Hi Citric,
unfortunately I can´t see the pic. Would love to see your toys
Maybe it´s the forum misbehaving again? Did you use the img tag to post the pic?Yeah unfortunately with the very cheap ones it´s hit-and-miss. We do have a 5$ no-name USB Midi cable here that works perfectly for uploading SysEx, but have seen one that looks exactly the same that didn´t work.
The cheapest name-brand interface that we´ve successfully tried was the M-Audio Midisport Uno.
I would hope that their build quality is more consistent…