It would be nice if there was some automation where overbridge took the mono tracks, turned them into stereo tracks in the daw, and used the pan parameter from the device to pan the tracks.
It is total bullshit that the panning isn’t transferred via OB. The fact that you can go into the hardware and make a full song, with tons of panning automation/lfos/plocks/etc., then when you try and multitrack it via OB, it’s all lost, is a goddamn shame.
It has, unfortunately, rendered OB completely useless for some of us.
Damnit.
Oh well!
1 Like
I wonder why DT/ST doesn’t have stereo individual outs same as DN, is there a difference in their DAC positioning for the digital voices?
not sure - i think the DN is just different ‘because’ … doesn’t it require two DSPs, maybe they had a bit more ambition there (especially if only 4 tracks to begin with) - maybe the voice allocation algorithms benefit from it 8 outs - but for whatever reason it’s an outlier (i wasn’t especially aware of the distinction until @DaveMech et al mentioned above as i don’t much care about OB)
Maybe it was set up with the DNK 4x2 outs in mind - i was a very late adopter of the DN, so didn’t tune into the chat at the time
my gut reaction is the total ‘streamed’ channel count is a factor
2 Likes
That’s what I mean, but it must be very complicated to implement, otherwise they would have done it.
what I just can’t understand why the expensive ones don’t get cc control. I do not get it. because that would sort of fix the problem.
sorry, I don’t understand this part, I tried looking at the previous comment as well but I don’t follow, are you trying simultaneously control rytm pan from daw and midi controller?
or do you want to control external gear with the rytm encoders?
not an issue, it’s not that easy for me to explain it either, because english isn’t my mother tongue.
I’ll try it very briefly: it is possible to control any controller from the DAW via the machine with DN, DT and OT, because the machines mentioned allow CC control.
This means that you can assign the pan control from the channel of the DAW to the machine, thus avoiding the problem. he can p locking with the pan is possible without any problems.
the cc control via the device would mean much more. you could also edit the effects etc with the p locks without having to automate everything in the DAW in a complicated way. it would be a symbiosis with the machine.
I found someone here who explains it very well:
so you mean midi tracks? yeah there’s no such thing on the rytm, the midi out capabilities are very limited, but imo it was never meant to do that.
I mean, it’s an analog synth and sampler, maybe it’s not the best midi controller/sequencer, and probably never will be.
yeah I understood that… again, not what rytm was meant to do, basically it’s more of a live performance focused, so while other machines have some advantages they also lacking where the rytm is strong, trig slides, mutes, pads, etc.
you can’t have everything in one machine, just enjoy the rytm as is 
come on elektron give us that for the rytm and a4 - that just can’t be.
I just can’t imagine that this isn’t possible, because all the other devices can do it too.
they made it very very clear that they were only ever going to get very bare bones midi note support - it’s not a reflection of ticket price, it’s just not what they conceived the device to be - the late midi addition was after much arm twisting, the prospect of any deeper midi control out from the analog big boxes is low imho
Oh, I didn’t even know that elektron mentioned it before. Yes, that can be anything and it would simply be a great feature for the large, expensive devices.
It could be but if the software architecture was never conceived/designed to have that feature from the beginning, any later addition will suffer from increased complexity in the code, not only to make it work but also to not break any feature that is already there.
I refer you to this recent thread to see how something that looks “simple” or “should be” sometimes are not simple or easy at all to be added later in the design: "It should be simple to code"
2 Likes
yes, all machines have their advantages and disadvantages, so buy them all - that’s probably the philosophy behind it.
maybe one day elektron will build a monster box that can do everything + all sorts of features.
i respectfully disagree - they are providing focus
kinda like the OT which has a horrible UX imho - they threw the kitchen-sink at that and it suffers (by comparison to the devices which followed)
nonetheless - there are Feature Request topics for stuff like this - keep in mind that greater Midi functionality is infinitely more doable (although very unlikely imho) compared to having stereo/panned individual tracks (restricted by hardware layout)
Each time they make something, they aim to make the best version for its market position - i don’t think it’s driven by any of the arguments used to explain perceived shortcomings - that’s my take
sounds awfully like an awful computer to my tastes - each to their own
1 Like
I sometimes wonder if I come across as sarcastic with what I write. As I said, English is not my mother tongue.
I have absolute respect for elektron and am still enthusiastic about their work. to be honest, it’s actually one of my favorite hardware devices.
it would just be a nice feature for the big boxes and i’m pretty sure it would be possible.
Doesn’t DN still has panning in OB?
I don’t think you are coming of as sarcastic so no worries. I just believe you haven’t internalised some of the comments here, for example:
Yes, it could be a nice feature but every single product you use is designed, the design will be based on some requirements and a vision of what the product should be, how it should become that, how it will be interacted with, etc. The design of these boxes didn’t account for that, it was not part of the “brief”, it was not something to be thought and considered to be implemented from the get-go, so to add it later creates complexities.
And yes, it “would be possible” but… At what cost? Not only financially but cost in UI/UX trade-offs, someone has to go through the design process to figure out how it could work from an user’s perspective, how to make it easy and usable. If the hardware is not capable to do it then it’s physically impossible with the current hardware, if you are wishing this to exist in a future hardware: what financial cost would this entail? Is it worth to pursue this feature or are there others that could be implemented and would be more aligned to the product’s vision?
I think that’s the issue you are not internalising, in software a WHOLE LOT can be done but everything, every single choice has a cost and a trade-off, you have to balance all of this to come up with a complete product. It’s possible but most of the times not simple nor easy, nor cheap.
1 Like