Anacreon Synthesizer | Anacreon 2.5 Released

VST, AU, AAX, etc. plug-in Virtual Instruments discussion
falkTX
KVRist
141 posts since 19 Sep, 2007 from Viseu, Portugal

Post Sun Oct 10, 2021 2:53 am

Erich.Pfister wrote:
Sat Oct 09, 2021 8:56 pm
BTW I saw the debug variable and set it to true, but it's still not catching the entry point...
I would say to try to remove the dll exports, since that is something that I know makes this work on linux.
Just delete the whole "Set plugin symbols to export" section on https://github.com/DISTRHO/DPF/blob/dev ... ns.mk#L114 and relink.
If windows works like linux on this, you will get debugging symbols.

User avatar
Erich.Pfister
KVRist

Topic Starter

203 posts since 24 Jul, 2020

Post Sun Oct 10, 2021 8:11 am

crickey13 wrote:
Sun Oct 10, 2021 12:41 am
Good to see you back in stride, Erich. It's always sad to see softsynth projects being abandoned or stranded, so it's nice to see Anacreon being still developed.

BTW, I've been recently reading a book about Ancient Greece and I came across Anacreon at one point, instantly thought of your synth. :hihi:
Hey thanks crickey! I'm feeling pretty good - Anacreon will never be completely be abandoned, but there will be long periods of time where I can't work on it. I wish I could promise a more consistent schedule, but I'm just not a consistent enough person right now. I will say that I feel engaged and that I'm not feeling discouraged about the issues I'm facing with Anacreon currently. Usually what kills it for me is a ridiculous bug that never resolves!

Anacreon was a pretty cool guy. I like his character a lot - nice to know Anacreon synth is living in your head rent free lmao! Hope you're having a great day.

User avatar
Erich.Pfister
KVRist

Topic Starter

203 posts since 24 Jul, 2020

Post Sun Oct 10, 2021 8:35 am

falkTX wrote:
Sun Oct 10, 2021 2:53 am
Erich.Pfister wrote:
Sat Oct 09, 2021 8:56 pm
BTW I saw the debug variable and set it to true, but it's still not catching the entry point...
I would say to try to remove the dll exports, since that is something that I know makes this work on linux.
Just delete the whole "Set plugin symbols to export" section on https://github.com/DISTRHO/DPF/blob/dev ... ns.mk#L114 and relink.
If windows works like linux on this, you will get debugging symbols.
Falk,

Thanks for your help! I'm planning to make the "set plugin symbols to export" section conditional based on whether or not DEBUG is set to true. Is that something that I should submit a pull request on after I've done it or is this too specific to my use case to be a library feature?

Thanks!

falkTX
KVRist
141 posts since 19 Sep, 2007 from Viseu, Portugal

Post Mon Oct 11, 2021 6:01 am

Yeah that should be pretty simple and ok for a first PR!

User avatar
Erich.Pfister
KVRist

Topic Starter

203 posts since 24 Jul, 2020

Post Sun Oct 17, 2021 8:22 am

falkTX wrote:
Mon Oct 11, 2021 6:01 am
Yeah that should be pretty simple and ok for a first PR!
Hey Falk - in your experience, is there anything preventing a plugin from having non-sequential parameter ids across the platforms you've implemented with Distrho? I'm planning to use bitfields to encode a 31 bit hierarchical addressing system for parameters so that I can add and remove parameters more easily without breaking between updates.

Edit: And that address is stored as a uint32 parameter id.

falkTX
KVRist
141 posts since 19 Sep, 2007 from Viseu, Portugal

Post Sun Oct 17, 2021 9:24 am

For VST2, VST3 and LV2 this doesnt matter at all, kinda.
DPF (from your provided info when creating the plugin) assigns a dedicated symbol to each parameter. So saving and restoring state is pretty safe when it comes to parameters additions/removals.
But automation is not, so something to keep in mind (LV2 is always fine though, as the spec dictates to always use symbols to refer to parameters, never indexes)

If you want to be extra safe, reserve some parameters and just don't set the attributes to make them automable on the host, calling them "unused" or something.

It is not good practice though. Preferably if you add new parameters often the best is to put them after the old ones.
Last edited by falkTX on Sun Oct 17, 2021 9:43 am, edited 1 time in total.

User avatar
Erich.Pfister
KVRist

Topic Starter

203 posts since 24 Jul, 2020

Post Sun Oct 17, 2021 9:38 am

falkTX wrote:
Sun Oct 17, 2021 9:24 am
For VST2, VST3 and LV2 this doesnt matter at all.
DPF (from your provided info when creating the plugin) assigns a dedicated symbol to each parameter. So saving and restoring state is pretty safe when it comes to parameters additions/removals.
But automation is not, so something to keep in mind (LV2 is always fine though, as the spec dictates to always use symbols to refer to parameters, never indexes)

If you want to be extra safe, reserve some parameters and just don't set the attributes to make them automable on the host, calling them "unused" or something.

It is not good practice though. Preferably if you add new parameters often the best is to put them after the old ones.
Believe me - I've thought of putting the new ones after the old ones, but I'm doing a bit more than I said in my previous post. I want to allow a variable number of each module (osc, filter, etc) type via config file, and I want any patch made in Anacreon to load on any config that has at least the minimum number of the different modules required, and I want all automation saved by the host to match up perfectly so that people (like me) who don't use presets but use whatever the DAW provides for saving stuff.

EDIT: I can think of a few different ways to achieve this with a continuous block of parameters.

falkTX
KVRist
141 posts since 19 Sep, 2007 from Viseu, Portugal

Post Sun Oct 17, 2021 9:51 am

Well I guess this is more of a general problem rather than be something specific to DPF.
You just need to find something that works well enough.

User avatar
Erich.Pfister
KVRist

Topic Starter

203 posts since 24 Jul, 2020

Post Sun Oct 17, 2021 10:06 am

falkTX wrote:
Sun Oct 17, 2021 9:51 am
Well I guess this is more of a general problem rather than be something specific to DPF.
You just need to find something that works well enough.
falkTX - it is a general problem but your help definitely provided a constraint that I wasn't initially aware of, so thanks for clarifying that!

Return to “Instruments”