New PluginHostType to be detected


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:

        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)


Ok, thanks, I’ll add that.

I think it should look for more than “sam” though! I guess “samplitude” would do the trick?


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)


Wow, if that’s how they name their exes, I’d hate to see their variable-names!

Maybe the path could be used too? Is it always in a samplitude directory?


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”


Ok, thanks.


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?


There were two lines detecting reaper - I just got rid of one of them… (or did I misread something?)


ah yes, my fault, I didn’t see the duplicate because I only checked the diff, and the line above was untouched :slight_smile:


path is: “Image-Line\FL Studio 9\FL.exe” or “FL (extended memory).exe”


Ok, I’ll add something for that…


REAPER could be detected on Mac also:

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)


But if it used equalsIgnoreCase, then it’d always fail because of the “.exe” or “.app” suffix…(?)


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)


Yes, fair point!


Cubase 6 and Cubase 7 join the family of detected host types:


Yep, thanks, will add them.