03-17-2021, 02:06 AM
Hi House of Kris always a pleasure to hear from you!
thank you so much for your well wishes!
here is the thing: when dealing with the midi specification and legacy hardware that is often either vintage(EMU company not in existence), abandoned(Roland mv8800 and everything they release after 1-2 years), or no room to grow(radikal technologies spectralis has its entire OS on 768k)...its often on the onus of the newest product being introduced to help make life a bit easier in regards to connecting to the legacy they seek their product to be a part of(i.e. customer support)
In this case it's the NDLR and the gracious use of midi cc assignments(versus sysex) to control just about each and every aspect of the sequencer. The last sequencer that was capable of controlling the bpm assignment in my possession was the DSI evolver/polyevolver...and in order to do that had to be switched to the master of the chain.
I understand the why's and how's of what we all had to go through to get here. I also understand the difference of perspective and opinion that you are articulating in regards to feature depth and firmware updates/niggles/prioritization.
I would still want a simple filter switch to be able to control this kind of behavior due to setup. It's a nice idea in some situations and in others not so much, as I have gone into detail on previous posts. This is me noticing that the midi cc affects NDLR tempo in a bit of a clumsy (5-127 multiplied by 2...so no odds nor decimals). Mind you in certain circumstances this can lead to undiscovered worlds of temporal dialect where one is free to shunt from 1/4 to 1/2 to double time to normal time...and that propagate down the sequencer's tree....(but even then the options are limited due to the unavailability of odds and fractions)
I also get that maybe you just might come from an age of "just do without", or "just do it this way"...and I am not at all unfamiliar with that particular take...its just I would like to shield the bpm from inside the NDLR regardless of whatever data was entering through the midi's internal ports. This comes from being accustomed from companies like Elektron who provide an ear and consistent support to their once small now massive user base. Users get accustomed to features and being able to scrutinize the purchase they made with their discretionary income. Manufacturers in their right mind should love and look forward to hearing feedback of people who put the product through all the paces and test the limits and explore each and every nook and cranny. In that case users do what prototype and beta tester can't always find time for...(test , incorporate the product and assess in as multiple scenarios...whilst reporting and scrutinize their findings.) I also understand that this might be confusing to you and even have little value to you and of course you can also just scroll on and we leave it at that as I log my issues with the behavior on the site for the dev team to see.
Take care and stay blessed
thank you so much for your well wishes!
here is the thing: when dealing with the midi specification and legacy hardware that is often either vintage(EMU company not in existence), abandoned(Roland mv8800 and everything they release after 1-2 years), or no room to grow(radikal technologies spectralis has its entire OS on 768k)...its often on the onus of the newest product being introduced to help make life a bit easier in regards to connecting to the legacy they seek their product to be a part of(i.e. customer support)
In this case it's the NDLR and the gracious use of midi cc assignments(versus sysex) to control just about each and every aspect of the sequencer. The last sequencer that was capable of controlling the bpm assignment in my possession was the DSI evolver/polyevolver...and in order to do that had to be switched to the master of the chain.
I understand the why's and how's of what we all had to go through to get here. I also understand the difference of perspective and opinion that you are articulating in regards to feature depth and firmware updates/niggles/prioritization.
I would still want a simple filter switch to be able to control this kind of behavior due to setup. It's a nice idea in some situations and in others not so much, as I have gone into detail on previous posts. This is me noticing that the midi cc affects NDLR tempo in a bit of a clumsy (5-127 multiplied by 2...so no odds nor decimals). Mind you in certain circumstances this can lead to undiscovered worlds of temporal dialect where one is free to shunt from 1/4 to 1/2 to double time to normal time...and that propagate down the sequencer's tree....(but even then the options are limited due to the unavailability of odds and fractions)
I also get that maybe you just might come from an age of "just do without", or "just do it this way"...and I am not at all unfamiliar with that particular take...its just I would like to shield the bpm from inside the NDLR regardless of whatever data was entering through the midi's internal ports. This comes from being accustomed from companies like Elektron who provide an ear and consistent support to their once small now massive user base. Users get accustomed to features and being able to scrutinize the purchase they made with their discretionary income. Manufacturers in their right mind should love and look forward to hearing feedback of people who put the product through all the paces and test the limits and explore each and every nook and cranny. In that case users do what prototype and beta tester can't always find time for...(test , incorporate the product and assess in as multiple scenarios...whilst reporting and scrutinize their findings.) I also understand that this might be confusing to you and even have little value to you and of course you can also just scroll on and we leave it at that as I log my issues with the behavior on the site for the dev team to see.
Take care and stay blessed