Detect if an AudioDevice object is part of sampler dsp lane or normal


I have an AudioDevice object. It might be in the samplers dsp lane or in the track dsp lane. Can I determine this, only knowing the AudioDevice object?

You can examine whether or not there is an audiodevice object within each track or within each sample_device_chain of the instrument.

AudioDevice is a track or instrument dependent class, not the other way around.

Yeah, that’s the problem. It causes a ton of nonsense calculations. In a real object oriented structure, there would be some kind of method like:


or something. Or at least .parent()

In other cases it does exist, but I don’t think I’ve seen it available for AudioDevice.

>>> oprint([1]:device(1))
class: AudioDevice
>>> print([1]:device(1).device_path)
>>> print([1]:device(1).display_name)
>>> print([1]:device(1).name)
>>> print([1]:device(2).name)
Bus Compressor
>>> print([1]:device(2).display_name)
My Bus Compr.

If .display_name were unique it would be easy to locate within tracks and within sample_device_chains. It would just have to be traced.

>>> print([1]:device(2).device_path)
Audio/Effects/Native/Bus Compressor
>>> print(
Audio/Effects/Native/Bus Compressor

The .device_path also does not provide relevant information. I thought it would signal if it belongs to a track or to a sample_device_chain.

It is correct that the device path stays the same, since it only tells about the used plugin. But if Taktik is not willing to add at least some of basic oo style methods like .parent() and .context() (not idea why he refuses this really, since it would save a ton of iterative code and performance), there could be a second path like “current_path” or so, giving the parent type (track or instrument dsplane) and the position(s) in the parent.

But all those kind of nonsense loops in loops, just to find the used object, that makes no sense at all, is a performance hog and also not well nicely designed then. Maybe Taktik refuses to add parent object references due xml serialization or something. Or he thinks that this at a whole is an outdated concept, not worth to be structurally improved. Maybe he already wrote about this and I forgot that…

You are saying that if you think of something (more complicated than just one line/one shot things) to script you have to write ‘searcher’ function(s) that (attempt to, can fail due to lack of info) search for what the object is in relation to the whole state of other Renoise objects(?) Sounds like Renoise-lua programming.

Vaguely related:[].group_parent exists though. I think that one happened due to popular demand :slight_smile:

1 Like

The point was that the Renoise API lacks of a real object oriented structure. OO style programming not only can give performance benefits just like here, it also is way better readable and maintainable. Taktik knows all this very well. If Renoise really was using references on objects, there would no need to iterative over arrays/tables just to get some object infos.

Renoise lua lacks enough thought.

I mean it is awesome that our favorite DAW provides such a complete API. No other DAW has that. But with possibilites there come wishes for improvements hehe

To be truthful, I wouldn’t of put any scripting/language facility in the Renoise software.

Why that?

Speaking if I was writing Renoise, complexity ffx (as taktik has probably shown.)

Yeah a pity then it’s not open source then. Or open source but with commerical license. Or partly open sourced.