RobinSchmidt
Are you doing something that overrides Jucer Is A Synth setting?
PrettyScope refuses to be considered an Audio Units FX, it seems.
Is there something you did in your framework that would mess with this?
looking at the doc of juce::AudioProcessor:
https://juce.com/doc/classAudioProcessor
i can't find any function like isSynth() or something that which i could have overriden for this. do you know or can you figure out, what exactly the effect of this jucer macro is in code? i guess, it will determine the return value of one or more functions. the only thing that goes broadly into the direction is acceptsMidi - which i indeed override in AudioPlugin (where it returns false) and its subclass AudioPluginWithMidiIn (where it returns true)
ok, this is not the problem.
Logic is just f***in' messed up. It works in GarageBand which is pretty fussy. Logic must be insanely fussy... It just doesn't work in Logic as an FX, but it does work as an instrument. ****
hmm...strange. i have no idea. do you have the same problems with your other plugins or is this specific to prettyscope? if so, you could try to figure out, where the difference is.
i actually find it generally quite annoying that some hosts distinguish between synths and fx. i don't really see the point in this distinction. it creates more problems than it solves
this would affect all my plugins, yours as well. Although PrettyScope is the only fx I've tested.
so, they will all be recognized only as instruments and not as effects? hmm...the question would be, what exactly determines, how logic categorizes a plugin. what in our code and/or in the jucer settings determines this? there is this "is a synth" field in the jucer. i can't find any corresponding function in juce::AudioProcessor - so i guess, it's not overridable from the code side. but if that doesn't work, it's weird. but then there are also, these various "category" fields, "AU Main Type", etc.
i should have been more detailed about the problem.
When it's marked as an FX, logic does not show the plugin in its available plugins list. That's the problem. It doesn't even allow you to see it/load it.
But this is a very limited test, one user and one project. It would be a good idea to make an FX version of toolchain and test in Logic, but I don't have Logic. I would have to make Alejandro test it.
toolchain actually is an effect anyway. at least, i don't have the "is a synth" checked in my jucer file (and never had)
btw. - i started a new project. i finally want to write my dream synth for toolchain. a semimodular architecture with 4 sources (with vector-mixer), a dual filter (also with a sort of vector mixer for mixing various configurations) and an arbitrary number of freely routable modulators. into the source and filter slots, the user can insert oscs, samplers, noise-generators, physical-models, whatever - the same goes for the dual-filter slots. "filter" is not to be taken literally, it could also be some other process. also, i want to allow the sources to have inputs and the filters to allow for self-oscillation - and then perhaps provide the exact same collection of pluggable modules for the source- and filter-slots because the line between these two sorts of modules is blurred anyway
...that means i must make my runtime instantiation code for AudioModules more flexible and somehow have to make the mod-system polyphonic....new challenges ahead...
perhaps from the new flexibilized runtime module instantiation facilities (which i'm currently working on). ...oh...and polyphony handling.
oh btw i have a similar idea. for example i want to have a number of lfo options in place of my fixed lfo
chaosfy-style lfo, 2d lfo, xoxos osc as an lfo, how about a mini rayblaster as an lfo? i dont have to use that in my products, thats all yous.
oh also simple lfos / utility to remove some uneeded clutter when you just need a basic lfo.
2D LFO is interesting...but perhaps difficult to integrate into the mod-system. i need to think about, how this can be done. from the user's perspective, it perhaps makes most sense when the two outputs just appear as two separate modulation sources in the mod-setup
btw. i'm also currently experimenting with the xoxos osc, too. you can use that as 2D osc, too. just don't add x and y at the end but use them separately.
i think it's not a mod system problem but an interface problem. We would need a clever interface to make it easy to connect 2D prameters to 2D modulation sources. For example, an X/Y pad. OH! that's it!
For a 2D parameter (such as x/y pad) when you list modulation sources, you could list them differently somehow to make it easier to connect 2D modulation. Maybe you have to have a "group modulation" feature to say that these modulation sources should appear as a group. It's eally just a convenience thing.
mod source 1 goes to mod target 1 mod source 2 goes to mod target 2
Anyway, I think it's mainly an interface problem. No need to make the mod system more complicated.
I think it's mainly an interface problem. No need to make teh mod system more complicated.
well, you haven't written the mod-system - so how do you know, how hard or easy this will be? the problem i see is that the mod-system assumes there to be a ModulationSource object for each (1D) modulation signal. ...maybe for the second channel of some 2D modulator, we can create a kind of dummy-object or something...dunno
I'm just saying, if I designed a mod system interface, I'm sure I could have 2D mod source/targets without touching the mod system code.
Edit: Or the only thing that migth be needed is a group id or something, to group sources/targets.