Fixed coded object referencing instead of using an attribute?

#1

Is it possible to hard-code object references instead of using an attribute?
Eg. I have those scale/temperament banks/modules which always listen to the same module and only one is needed ánd which will always end up being "scale7bank_1". So couldn't I also just do this in the code so that people don't have to enter that each time... or is the patch-name embedded in the object-reference attribute?

Also I had an idea about a morph-option for single knobs/sliders objects with a centralised rate&morph control to be used with the preset-manager of the axoloti. But giving each single knob a big object-reference is kinda ugly... and waste of space..
so yeah, in these cases a hard-coded object reference would be nice..

#2

Hi SirSickSick,
I have been doing some object coding recently, and yes you can hard code references. It is as simple as replacing the attr_ code with a constant or variable.

Eg. from something I am working on:
MidiSend3((midi_device_t) MIDI_DEVICE_DIN, 1, MIDI_CONTROL_CHANGE +
(attr_channel-1),attr_cc7,__USAT(midiFeedback>>20,7));
This code is based on the midi cc out object. I have replaced the attribute 'device' with 'MIDI_DEVICE_DIN' which was in a spinner. It lives in a function in the local data tab.

Params can also be hard coded in local data. Hope that is what you wanted to know.

#3

I know these, but the object-reference attribute doesn't seem to respond this way.

#4

Right, I'm not sure what you are trying to do then, I will have to think about it. I'm pretty new to programming the Axoloti, but I generally know my way around a script. Could you explain better? Perhaps understanding your issue will help me somehow with my (numerous and complex) issues.

#5

object references are place holders, the issue is the reference you are after is the object id... not the class, so if you hard coded them, then if your user renamed the object , your dependent object would break...

if you have a situation, where you believe only one instance can exist of a particular object... and so you believe a reference is not required... then you should use a 'singleton' pattern. this is a common programming pattern that you will find if you google it, which basically uses a static variable so that other objects can find it. (I'm sure google will supply diagrams which will explain better than I can in text :wink: )

#6

thanks, I'll take a look at this.
It started mostly for my note scaling objects, as you'll only need one of these anyways and there ain't no point to renaming them.. It's not that people will need that name for another module..
Just load and forget.. every single note-quantizer will then automatically recall that single table-object.
Also, I've made different types of quantize-tables which shouldn't be used together, but the current way allows it to be used wrong, which would to wrong behavior of the module and unnecessary questions for me to answer..

Help with custom Send/Recieve code
#7

@SirSickSik

Did you find a solution for the fixed object references?

I could really use that for something I am working on at the moment.

Thanks!

#8

nope..haven't been able to do so

#9

Ahh Okay, what to do hehe :wink:

I tried looking up singleton as @thetechnobear suggested , but didn't fully understand it, so I guess it needs a little bit more research :slight_smile:

#10

sorry for highjacking the thread, but i have a question sligghtly related to this and you two guys probably know:

i have a poly subpatch that references several parameter data tables (512 size only) from the main patch. what's more memory efficient, having few big objects in the subpatch with the table obj_ref and lots of outlets going to the synth objects, or instead putting the obj_ref into each of the synth objects directly, resulting in much less inlet/oulet patching but a lot more table references?
does adding an obj_ref add a lot of memory overhead or addtl CPU cycles? compared to inlets/outlets.

#11

@weasel79

I am not sure about the specific numbers, but I would say that the less objects you have in these polyphonic subpatches the better, because everything you put inside will be cloned as many voice as you set.

But then again, some things just have to be inside the poly subpatch for it to work properly.

About using many table/object references, I am not sure if it is more heavy than using inlets/outlets, someone else needs to chime in here. But I think we are in an area where it tit makes very little difference, without really knowing.

If you want to measure if you add more cycles to the patch, you can try something like this: