Native arm version - testing EigenCore/ECMapper

Eigenharp
41

@Kai sent you another PR which fixed a few issues.

the main thing is… you cannot have VST2 support using the embedded JUCE vst3 sdk.
so for now, Ive taken it out.
Ive also removed some of the redundant code, that Id left in form when Id previously being using VST2 instead of vst3… makes things a lot simpler :slight_smile:

if you want VST2 support, then we’d need to add back the custom vst2_sdk path.
but I would also make the VST2 build optional, so by default the build does NOT require this sdk.
though, personally, Id not bother… for my vst projects, Im going to go remove all the vst2 stuff :wink:

also, ive changed it so the build defaults to a universal build rather than forces it.
(sometimes its handy to force a single architecture build)

I didnt change this… as this was a deliberate choice on your part …
but personally, id not included a version in the binary name.

this could cause potential issues with VSTs and host
the host uses the plugin code - not the filename, which if a user does not remove the old version, will now have 2 plugins.

also frankly, as a user I always prefer to just overwrite old versions with new versions of plugins and apps… if Im ‘concerned’, I will manually take a copy of the old version if I feel its necessary.

anyway… just my personal opinion, so Ive not changed it.

on my side, given the cmake universal build is working here…
I’ll consider converting my stack (MEC,EigenLite and libpicodecoder) all to universal binaries.

note:
this will be universal 2, so I believe thats only 64bit arm/intel, so no 32bit intel support…

note 2:
I wont actively remove 32bit support, but just wont distribute/support it.
so someone can build it themselves if they have the need for it.

2 Likes
42

Cool, I don’t care about 32bit or VST2. Thanks. I noticed the released XCode version was signed “adhoc”, so I added that.

Version in name:
Yeah, it is a deliberate necessity since I’m actually using the released version(s) in various Gig Performer Rigs on the same mac. If I’m not careful with what files are what, I’ll lose my settings in my rigs when I do some dev work. (or test the wrong version when in “developer mode”). The plan was to keep it like this while working, but then do the final release without when the time comes.

1 Like
43

I’m good testing, just let me know :wink:

2 Likes
44

ok, this would need to be optional… as not everyone who is building will have a apple dev cert to sign with…

I’ll lose my settings in my rigs when I do some dev work.

can you not version the settings file to prevent this? or are you worried about using the wrong version in GP and saving the gig performer setup?

also is a different filename for the plugin going to help you? I thought it’d need a different plugin code?!

perhaps the cleaner way around this is to have different names for dev and release builds?
that would also allow for the plugin code to be changed.
this limits to only two versions… and end-users would never see the ‘dev version’

anyway… all depends what you are trying to achieve… which is why I didn’t change anything in this area.