It’s possible to detect Magix’s Samplitude with the following additions to juce_PluginHostType.h:
an entry to the enum should be added at first:
SteinbergWavelabGeneric,
MuseReceptorGeneric,
MagixSamplitude, // this line to be added
};
the obligatory method for detecting whether the host type is samplitude
bool isSamplitude() const throw()
{
return type == MagixSamplitude;
}
an additional “if” is needed in the Windows section of getHostType ():
if (hostFilename.containsIgnoreCase ("Logic")) return EmagicLogic;
if (hostFilename.containsIgnoreCase ("rm-host")) return MuseReceptorGeneric;
if (hostFilename.startsWithIgnoreCase ("Sam")) return MagixSamplitude; // this line to be added
also, I think it’s more correct to use “startsWithIgnoreCase” rather than “constainsIgnoreCase” when only hostFilename (and not the whole hostPath) is to be checked. This, in case of very short host executable names, prevents some possible false positive detections (I thought about this when I realised that looking for the substring “sam” regardless of its position within the host executable filename seems pretty generic… I think it’s better to constraint this and the other such checks to find the string from the beginning of the filename)
no, unfortunately the executable name is “Sam.exe”. Maybe discarding the extension and looking for it to be exactly “Sam” is the way to go (I mean, still with case-insensitive comparisons)
Mmm… the installer defaults to a path that contains the “Samplitude” word, but I’d tend not to rely on that because someone (crazy enough) may decide to install it somewhere else.
Maybe the exact match for the filename without extension is the way to go. After all, I can’t think of many other hosts that could have such exact executable name…
in addition, keeping the shortest checks at the bottom will result in better matches to be found and returned earlier, thus avoiding some “false positives”
I noticed you have committed this change, but I wonder why you have removed the line that detects Reaper… it looked valid to me, and in addition you didn’t provide any other way to detect it… am I wrong?
if (hostFilename.equalsIgnoreCase ("REAPER")) return Reaper;
and I think there is a isReaper() method missing as well, something along the lines of:
bool isReaper() const noexcept { return type == Reaper; }
For REAPER on the Windows side, I think that using “equalsIgnoreCase” instead of “containsIgnoreCase” is more appropriate (and is possibly more appropriate for a number of other such detections as well, for both Mac and Windows, to avoid false positives)
As for the Mac apps, the filename is the one of the actual executable (that has no extension) that is contained in the bundle (that is the one with .app extension) so equalsIgnoreCase is ok (I’m already using it and it is working for mac), but you have a very good point for Windows executables.
What about using getFileNameWithoutExtension () to retrieve the hostFilename? None of the current detections uses the extension of the executable, and I think it’s reasonable to think that no one will, as it is given for granted that the hostFilename is the name of an executable file for the current operating system and the extension is implied by that?
Otherwise, you could keep the getFileName () call and still restrict the Windows detection calling equalsIgnoreCase (“reaper.exe”), startsWithIgnoreCase (“reaper.”) or something along those lines (and do the same for a number of the other entries as well)
Good suggestions, but is there much danger of false positives? There can’t be an awful lot of hosts out there, and almost all of them are on the list, which seems to have been working fine… It doesn’t feel like it’d be worth the time to go through and change it all (and in doing so I’d probably end up breaking something else)
I’ll certainly add an entry for reaper on OSX though, thanks!
Ok, I agree about not changing the current implementation for not breaking existing code, but still I think it would be a good practise to use the strictest possible condition to detect hosts that will be added to the list in the future, and thus also put those checks at the top of the sequence of ifs in order to verify the (new) strictest conditions first.
(maybe, leaving a comment there with instructions on how to add future entries could be a good idea as well)