@griffinboy funny. I talked about making something like this a couple of years ago when access-analog started ;) such a good idea. sadly it only works with midi devices I guess. imagine this for really old gear

@Christoph-Hart

As always, thanks for the response: )

@aaronventure oh yes I always forget that the CPU is in charge… pity…

Yeah I simply dropped the stock blur for a long time, eager to see melatonin being implemented more deeply

@HISEnberg

2012/GiannoulisMassbergReiss-dynamicrangecompression-JAES2012

Search this online

@ustk

Oh no way, thanks.

It's funny I had plans to integrate it myself and was very surprised to find it had been sneakily introduced.

@d-healey But in this case that would mean delivering the file in question along with the binary, right? I am not sure it is "appropriate" for a neural model.

@griffinboy Why not simply paste it in an included script file that only serves this purpose? After all, having an include line or a variable you load a json into, there are not much differences in terms of code weight

@Christoph-Hart

I think there might be a glitch here somewhere. Another one of my projects has suddenly stopped working with my polyphonic filters. I'll do some investigations

@griffinboy the SNEX API has three main container types and if you want to use the index template for interpolating / safe access you need to use them. They differ in their ability to change their size dynamically and whether or not they "own" the data:

span: owns the data, compile time size (allocated on creation) dyn: doesn't own the data, only refers to it heap: owns the data, but allocates it dynamically

The easiest entry into this would be creating a dyn<T> container with a simple T* pointer and a size. Almost any container in the world will give you access to the raw data. Here's a std::vector<float> example:

std::vector<float> x; x.push_back(1.0f); x.push_back(1.0f); x.push_back(1.0f); dyn<float> snexContainer(x.data(), x.size());

@griffinboy

and will there be automatic voice stealing if I do so?

@griffinboy I'll try and take a look at it later today if I have a bit of time.

@d-healey

Thank you, really useful

@griffinboy The pleasure is mine! You know, I'm trying to improve my skills lately... This way I will be... 😝

@griffinboy said in Global Cable Bug::

@Lindon

From what I've seen, removing all code that uses a cable, or removing the global cable manager, does the trick: they all disappear.

But yeah, I've not used cables much I've always had issues with them. But they seem to work now, just not in this one project 😆

yeah Ive done this:
"removing all code that uses a cable".... its still there - maybe I missed something.

Thanks I took a proper look and I was just misunderstanding it.

The instructions tell you exactly what to do.

I think I fell into a trap because I coded up my nodes when i only had one global cable.

When you ask Hise for the GC C++ code for more than one cable, it becomes clearer how it's working.

// Use this enum to refer to the cables, eg. this->setGlobalCableValue<GlobalCables::GC1>(0.4) enum class GlobalCables { GC1 = 0, GC2 = 1 }; // Subclass your node from this using cable_manager_t = routing::global_cable_cpp_manager<SN_GLOBAL_CABLE(70357), SN_GLOBAL_CABLE(70358)>;