Cross fader scenes and midi cc

Elektron Gear Octatrack
#21

On the other hand, it still may be musically useful.

I’d rather have the possibility of choking receiving gear and having it lock up/burst into flames and then adjust it for my own use rather than having someone else put in extra seatbelts, a governer on the engine, and wrap me in bubblewrap.

Back in the 90’s there was a MIDI sequencer called the Latronic Notron. It was one of the very few hardware MIDI sequencers ever made that sent out MIDI CC info between steps. Every couple clock messages (depending on tempo) MIDI CC info could be interleaved. If you had all 4 tracks set to the same MIDI channel and all 4 generating CC info along with notes, and had the tempo cranked up, different MIDI gear would react very extremely, but repeatably.

Do I get upset when an MKS-80 locks up with that much MIDI data spit at it? No. Do I enjoy the sonic mayhem that can result when a more modern polysynth like a Waldorf Q receieves all that info? I sure do.

The choice is mine and that’s important to me. Don’t block the ability to explore the extremes because often you’ll find very useful things near those extreme conditions.

Elektron used to be about exploring the boundaries and new ideas.

What happened?[/quote]
While I do personally agree very much with you regarding this perspective on gear/setup, I´d be a bit more cautious in such statements myself.

Abusing your gear is fun and can provide very interesting and/or good results (i e music). But downside is that abusing your gear can potentially mess it up as well. In worst case, badly. There might be a certain things under the hood that´s supposed to be there for developers, but not for the end-users.

I think most developers in the world are trying to develop their things to what they´re supposed to do, if that means taking an ‘shortcut’ to avoid unknown events to occur (‘governing the engine’) by just shutting certain abilities off. I can understand that decision. Because other way around, leaving the ‘door open’ can be such a devasting experience for a end-user if it happens at the wrong place at the wrong time in the wrong way. Wishfully, in a perfect world, an developer would design a system to handle everything that covers all potential conditions in every aspect. Not only internally but externally (such as when any other gears are connected).

Given the amount of parameters/MIDImessages that exists in many complex gear today, it borders on being an infinite project designing such perfect system. Not to mention the huge amount of tests one would need for such system. In space-, weapon- or medicalindustry there are such requirements. And the price are often related to that. In the musicindustry (consumer price), it´s easier to just disallow certain things in the first place in the system of a unit.

If everything were possible to be setup by the enduser, it puts an enormous responsibility on that person to actually set all system parameters correct (i e requiring professional understanding of the gear). Not to just deciding how to handle what´s happening, but also deciding on how to handle what´s not (supposed to) happening. Especially if it means that the end-user would have to buy and carry around extra peripheral gear just to avoid certain conditions/events.

As an example of what I´m meaning (my very own experience):[url=“http://forum.fractalaudio.com/axe-fx-ii-bugs/82285-possible-bug-reception-song-position-pointer-messages.html#post998561”]
http://forum.fractalaudio.com/axe-fx-ii-bugs/82285-possible-bug-reception-song-position-pointer-messages.html#post998561

It would be a bit stretched if a end-user like me (quite experienced but not professional) are supposed to set certain ability of reception of specific messages to OFF. Because of not limiting the abilities of the unit. Regardless of if it´s designed to do something with these messages or not for me as an end-user. These kind of experiences as in the above link, makes me worried about if there are any other MIDI messages (and/or combinations of them) that actually would brick my (US 2199.95 / EURO 2349.00) unit. Would I be able to afford a new unit, if out of warranty? Would any manufacturer accept liability because leaving all ‘doors open’?

Many end-users doesn´t want to go down the analysis road to a deeper understanding of their gear. To be able to abuse their gear and learn how to avoid certain situations. Many just want to make some music at their level of their understanding of the gear. I´m happen to be both at times, and I get the impression of many you here in this thread are quite similar in that regard.

With that said, I´m also hoping for certain possibilities in the OT becoming ‘unlocked’.

#22

I don’t think it’s the gear at the other end that they’re worried about. I’d suspect that it’s MIDI timing. The fact that you can modulate MIDI with an LFO implies that it’s not a big problem as long as the Octatrack can predict when the modulation will happen.

Timing and synchronisation is a black art and I’m sure that Elektron would prefer not to get the name that Ableton has for poor timing with people who don’t understand all the low level details (I know I don’t want to worry about them, as much as MIDI scenes would be very useful).

#23

Well, MIDI is indeed really old and slow. I´m surprised that it actually survived this far. In many cases it is still enough, but as soon as you enter into something more advanced (of wrong sort): huge bottleneck.

Worrying about gear at the other end, was more my view on it than anything official of Elektron. Because it relies on a bit deeper understanding on what MAY happen when having several complex units connected together. MIDI filter is the best friend here.

With that uncomfortable experience I realized that sometimes more ‘options’ isn´t always the better because I may need to dig deep, especially when I may not WANT to do that. But then on the other hand, I´m pretty much in the same boat as you. I do prefer having all the options aviable and clearly stated in manual etc from the beginning, and that I need to learn understand what they mean and turn the unnecessary ones OFF. Even if it´s just for being used together with other gear only.

Song Position Pointer, wasn´t (still isn´t) anything of use in that AxeII. So this seemed to be some kind of a bug only, however with the effect of making my unit seemingly broken. But I could figure out the issue myself and temporarily fix (filter) it externally. I do understand though that many others may not come that far on such route and would have prefered the fix/filtering (= coding) already being at the input to the unit, with the end-users being fully unaware of it.

MIDI scenes would indeed be very cool.

#24

Thanks for taking the time to reply. I’m not going to quote it all since other readers can just follow along.

Generally, I was speaking specifically about MIDI possibilities and/or limitations. I certainly understand limits on voltage ranges for cv control for example.

I am sad to see your issue with the AxeFX II unit since those are well-regarded effects boxes.

I used to do a lot of beta testing for music hardware. In the early stages of development, the easiest bugs to find and write up were the edge cases. What happens if I set everything to 127 (or 0). What happens if I apply the same modulation route multiple times? What happens if I apply the same modulation route twice with inverted amounts for depth? etc.

In doing so, I would regularly come up with interesting and musically useful combinations. As a direct example - when I first got the Octatrack, I was unimpressed with the retrigger stuff (RTRG, RLEN). I initially found it to be a bit of a novelty effect and wondered why it was on the main front panel controls. I was trying to use it in a normal way (retrig values of 2 to 8, lengths set to tempo-related intervals). Once I started playing with the extremes and then adding LFOs, a whole new branch of sonic possibilities opened up with just those 2 controls.

Getting back to manufacturer responsibilities, I disagree about the complexity and nearly infinite time to design and test. I work in the world of software development. I can assure you I have worked on systems orders of magnitude more complex than an OT and somehow they’ve managed to be up and running and the users are happy with it. Sure, bugs are found and fixed, but it was manageable to design, build, and maintain.

One of the keys (and of of the keys for success music products IMHO) is to give the user a bunch of simple to understand and use functions in a larger context that allows them to mix and match and apply the simple functions to create complex results. Again - I go back to the Latronic Notron sequencer. No display, a bunch of buttons and some knobs and wheels. A manual full of pictures and wide margins, often with pictures in the margins, and a easy to read font needs only 58 pages to describe the entire machine including sysem setup/configuration options. What you can do with those simple functions is mindblowing because they can interact and overlap in all kinds of weird and wonderful ways.

If the designers at Elektron sat down and created small, simple, easy to understand functions for a product, they should be easy to test in isolation. Once you have fully tested modules, plugging them into the system and testing the interactions becomes cleaner (not necessarily easy!) because you know each module works as designed and you can directly see the system-level effect of adding a new module to the mix.

To me, some parts of the OT feel that way, especially the bits and pieces taken from earlier machines. LFOs for example work exactly how they are described and I don’t think there are any bugs or unexpected behaviors associated with the LFOs themselves.

Other pieces of the system feel less-well designed. It may be due to internal/hardware limitations, oversights by the designers/developers, or a conscious choice to take it a certain way, but in the end the result is confusing and possibly problematic for the end user.

Final note on testing and documentation. As a beta tester, one of my duties was to go through the printed documentation, check for spelling and factual errors, verify everything described works the way it was written, and to thoroughly test the product to try and find every possible bug a user would encounter. Documentation (printed or electronic) is not a luxury. If you don’t or can’t properly describe your product, you will be creating a larger burden for your support staff (which is probably understaffed and lagging behind on product knowledge anyway). That includes describing known issues and limitations. There’s nothing wrong with saying “please don’t send Song Position Pointer messages to our effects unit. We can’t handle it in the current release. It’s a known issue and we’re working on an update”. Or, delay the release to fix the problem.

Again - talking about just MIDI here. MIDI is a well-known and thoroughly documented protocol. There’s no mystery about what messages can be sent and received, there’s a well-defined order and limits to each type of message, and there is a lot of code out there that successfully processes MIDI messages. If you don’t have a software program or programs to generate all the possible MIDI messages across all the channels and value ranges, then you as a company are not doing your job properly. Invest in automated tools to shake out the basic things early and often.

I understand that the quality and number of testers available varies and they sometimes don’t have sufficient extra resources to help test lots of use cases. However, that doesn’t excuse a company from releasing products with known, easy to find, significant bugs. Some releases (Elektron is not the only company here) feel like they followed the “developer codes new functionality” -> “developer compiles new code successfully” -> “developer creates patch release” -> “update sent to users” path.

In general, I find the Elektron products to be interesting and to be solid in their functionality. I owned a MonoMachine and a MachineDrum before purchasing my first Octatrack. I wasn’t there for the initial OS releaes of those other two products, so I don’t know what kinds of growing pains they went through before becoming the stable workhorses they are now, but I do know that the entire Elektron product suite was much smaller back then and Elektron could dedicate more resources to addressing bugs and creating new functionality compared to the current state of affairs with the Analog line, Overbridge in development, and the OT, MnM, and MD still around as well.

This ended up being much longer of a response than intended, but I hope it helps understand why I comment so intensely on OT issues. I love the box and own more than one. I just wish it had gotten more attention before Elektron spread out to all these other areas. Despite the recent comments by staff, it does feel like the OT has been left behind.

3 Likes
#25

Thanks for the long response, you´re probably correct on many levels.

Nothing is stronger than its weakest link. When you´ve got more than one issue, of any sort be it testing, documention, compatibility or whatever. It can feel such devastating to find that even when you/someone try to do the best on your/their part, it fails on something completely else. Anyway, each step is worth something in the end I guess.

Just being curious: any model/brand you´d like to reveal being involved in beta testing of?

Thanks regarding AxeII, it isn´t really an issue anymore. I think they fixed it in next FW released (haven´t checked though). However, I had quite an experience just a week ago prior to a gig which again reveals how sensitive certain things can be depending on the expectations and assumptions one makes sometimes.

A midi footcontroller (Nobels MF-2), banks are grouped as 0-9. AxeII, does however group (read) them (the PC# messages) as 1-10. Or if was the other way around. Anyway, whenever I recalled an PC#. It was one number above than the number intended that got recalled on the AxeII.

So I had to program my Midi Solutions Event Processor Plus, to do the offset. Of course this was discovered just the day before the gig… sigh…

#26

The ‘off by 1’ issue has existed ever since the first FORTRAN program was written. :slight_smile:

I’ve mainly been involved with Alesis/Akai. Tested the Andromeda (some of my patch submissions made it in the factory set as well), Ion, Micron, Fusion, and the MPC-5000. I spent a lot of time talking to and bouncing ideas and features off the guys that made the GenoQs Octopus sequencer, and have done some quick beta testing of MIDI functionality for the Bricasti M7 v2 OS. There’s some other products, but they were less formal (i.e. - no NDA required, spot testing of potential new features, etc).

I agree about the weakest link issue. it is worse these days (IMHO) due to the ability to have pre-release info leaked all over the world and customers having unrealistic expectations for delivery times and features. A company has to be very careful when discussing a new product (or potential new product) because there are so many links in the chain. Anything can set you back and then the internet community will kill you for it (cf - Akai Rhythm Wolf, DSI’s recent products, even the early years of John Bowen’s Solaris).

At the end of the day, a company has to be committed to delivering a quality product to their customers and they have to communicate that they listen and respond as well. Sometimes a simple - “yeah we have some open issues and we have developers and testers allocated to them” is all it takes.

During my professional career as software developer and manager of development teams, a lack of communication is the biggest cause of stress, misunderstandings, and unhappy customers. The customer (or manager) doesn’t need all the dirty details of what you are doing, but some simple status info, potential schedules, and general ‘I hear you and understand your concerns’ at regular intervals goes a long way.

1 Like
#27

Thanks, but that doesn´t help to know (about the offset)… :stuck_out_tongue_winking_eye:

I can imagine the amount of coming issues when I´m really going to implement my NM G2 Engine + OT + AxeII + etc…

Cool, regarding Alesis/Akai! They are making some great stuff. Have you been involved with the Alesis Dm Pro as well?

I´ve borrowed one of my drummer, and it´s great fun in combo of OT and G2. I made an test project where the G2 had 4 step sequencer ‘tracks’ running MIDI to the DM Pro, providing the hits to specific drums (NN#): i e the hihat, kick, snare and tom.

By flicking an button in the G2 editor (computer screen) I could choose any of the step sequencers values being randomized. Flicking another switch, I could have realtime selection of the sound in the DM Pro (via the OT fader) that these randomized values would play. So I didn´t need to do anything else than moving the fader and just listening to the sounds played by DM Pro. So the step sequencer (rhythm) that perhaps used to run the kick sound could now be the hihat instead. Whenever I wanted I could repeat the procedure, for the other ‘tracks’. And I had another switch selected between two PC# in the DM Pro.

So free automatic randomized rhythms x 4, free realtime selection of sounds for each ‘rhythm track’, and my OT ready to sample the results in perfect MIDI sync whenever I hit the rec arm button.

Arghh… so many ideas, so little time…

#28

Elektron could open up a couple of locks per track (or a maximum number, like in the AR)
That would take care of the bottleneck, and still give us something to do with the crossfader that is midi related.

5 Likes
#29

Sigh, this awesome update could have been the right one for it :unamused:

#30

Today i have got some kind of bug wich I can control de X-Y mix of my digitone via octatrack crosssafer. its insanly musical. Im gonna post a video on youtube so to give that idea to elektorn. its insanely musical.

#31

. Going to try that :slight_smile: is crossfader midi cc “accidentally” mapped to the cc on which the mix on digitone receives ?

Midi scenes would be such an epic addition to OT. What if it got implemented with a limit on the amount of scene locks available for midi scenes? Including a counter how many are left on a scene for instance.

1 Like
#32

Crossfader sends CC48. Can’t find a single CC 48 on Digitones midi implementation. Only MSB/LSB. (Delay ping pong on/off and ratio b).
Filter env depth on my Volca Bass can be controlled by CC48. That’s actually pretty cool if you have a synth where CC48 is mapped to a useful parameter^^

1 Like
#33

Not sure if it gonna happen. Who knows now? :content:
Would you use a midi processor? I planned to make a script for RK002 that would midi learn min/max, with different settings depending on scenes.

3 Likes
#34

Very handy to fine tune A4/AK! :pl:

2 Likes
#35

Nice! When I got my OT, I was kinda buzzed, because the crossfader controlled my Volca Bass, the internet said the crossfader does not send CC messages, though!
On that day I stopped googling for answers. Seriously.^^ I’ll rather take the time and scan through the manual.

On an older OS it actually didn’t send CC.

How would you implement min/max?

Sounds great!

#36

That sounds great. I actually have the rk002 :smiley:

1 Like
#37

Requires CC48 yes. On DN(DT too apparently), CC1-8 knobs respond to CC70-79. If to set your midi tracks on the same receive channel (in MIDI CONFIG), you can control them all, and they send their respective CC/Channel settings. I tested it successfully.

Ex with DN :
Set midi tracks to channel 5
Set different channels and different CCs for each track
use a controller sending CC70 on channel 5

With 1 knob, you can send 4 different CCs on 4 different channels.
8 with DT theorically.

2 Likes
#38

Asking Retrokits! :smile:
I already made one with their help, I’m sure they’d be interested in.
I may be able to decipher it with existing scripts.

1 Like
#39

Sounds cool.

1 Like
#40

I do it for Virus TI; but only six tracks and only a few cc’s; the midi stream is what the midi stream is.

2 Likes