Hi folks,
At least one person reported that, after first installing the Sub 37 Editor on OSX, the editor’s drop-down menus were empty / not showing any contents.
I’m just checking here to see if this has happened to anyone else. If you have seen this symptom at any point, please post here to let us know… thanks!
_Amos
I had that with the first firmware I tried - 0.9.25.
From memory, it wasn’t that the drop downs were empty so much as they simply wouldn’t respond and drop down anything. It happened a couple of times during my first session - it seemed to be after I’d moved the led brightness/contrast sliders. I can’t remember how I cleared it down - I think I just restarted the editor and sub 37.
I wasn’t able to replicate it, and it didn’t happen again, so I didn’t report it.
I can confirm that.
If it’s just the preset menus that were empty at first launch, this could be because GET all presets (into the Hardware Presets list) hadn’t happened yet. If the preset menus are still bank after getting all presets, that sounds more like a problem.
For me, it was all the dropdowns eg mod source/destinations - clicking on the arrow to the right of the dropdowns didn’t do anything.
Hi,
In my case, i get preset name (not sure if it was before first GETing presets) but category list is empty :
Then i noticed that not all categories are existing in the category list.
Exemple with ‘Rhythmic 5th Filtration’ (Factory B01-P01) which category should be DUO (it is on the Sub37’s LCD) :
Firmware : 1.1.13
Editor : 0.9.28 on OS X El Capitan v10.11.2
Sub 37 Editor 0.9.28
Install on 2015-12-31
I’m on a MacBook Pro, running OS X 10.11.2.
Here’s my experience with installing 0.9.28, with listings to show you what happens. It’s a novella.
I unpack the zip file, run the pkg file, answer the questions, and the application gets installed into “/Applications”, and a directory structure and some files get put into the user’s “Library/Application Support” directory.
I’m going to the shell (aka Terminal) to show you whats going on. For these listings, the user is “abc” in group “staff”, and the admin installer is “xxyyzz” in group “admin”.
After the installation of 0.9.28, the user’s “Library/Application Support” directory contains a new “Moog Music Inc.” directory – but it is owned by the administrator, not the user:
$ cd /Users/abc/Library/Application Support
$ ls -ld Moog\ Music\ Inc.
drwxr-xr-x 3 xxyyzz admin 102 Dec 29 15:53 Moog Music Inc./
Here is the contents of the new “Sub37” directory:
$ cd Moog*
$ ls -l Sub37
total 7448
drwxrwxr-x 2 xxyyzz admin 68 Dec 29 15:53 Hardware bank/
-rw-r--r-- 1 xxyyzz admin 810 Dec 13 2013 PresetCategories.xml
drwxrwxr-x 4 xxyyzz admin 136 Dec 29 15:53 Presets Library/
-rw-r--r-- 1 xxyyzz admin 1923816 Nov 11 11:25 Sub37 MidiPortHandler(x64).exe
-rw-r--r-- 1 xxyyzz admin 1882856 Nov 11 11:25 Sub37 MidiPortHandler(x86).exe
Everything is owned by the administrator, and the user can only read the setup files, and cannot write into the hardware bank (?) and the presets library.
Also note the two unnecessary Windows “exe” files.
Here’s the contents of the new Presets directory:
$ ls -l Sub37/Presets\ Library/
total 128
drwxr-xr-x 96 xxyyzz admin 3264 Feb 22 2014 Factory Presets/
-rw-r--r-- 1 xxyyzz admin 62899 Dec 10 03:13 Factory Presets.zip
And let’s look at some of the “Factory Presets”:
$ ls -l Sub37/Presets\ Library/Factory\ Presets/Tau*
-rw-r--r-- 1 xxyyzz admin 381 Dec 9 2013 Sub37/Presets Library/Factory Presets/Taurus I.syx
-rw-r--r-- 1 xxyyzz admin 381 Dec 9 2013 Sub37/Presets Library/Factory Presets/Taurus III Bass.syx
-rw-r--r-- 1 xxyyzz admin 381 Dec 9 2013 Sub37/Presets Library/Factory Presets/Taurus III Tuba.syx
-rw-r--r-- 1 xxyyzz admin 381 Dec 9 2013 Sub37/Presets Library/Factory Presets/Taurus III.syx
These are sys-ex files, but their headers are not Sub37 headers. I’m guessing that they’re for some version of the Taurus.
An additional problem: the “PresetCategories.xml” file has categories for some other device, not the Sub37 (see the date-stamp: 2013? for the Sub37?)
At this point, when running the standalone editor, not much works. The categories list shows only “All”, and none of the drop-down selection menus work in the various panels. You can tell it to fetch the presets from the Sub37, and it will do so. But after they’ve been downloaded, the application hangs, leaving the progress bar at 100%. I’m guessing that it’s because the user doesn’t have permission to write into the directories that the application installer created.
I have worked around this problem by going to the shell and fixing the ownership of the directories and files. In effect, something like this:
cd "Library/Application Support"
sudo chown -R my-user-name Moog*
chgrp -R staff Moog*
But since the standalone editor is happy with re-creating missing files and directories, then just wiping out the entire “Moog” directory might be good enough to fix this.
On OS X, getting to the library is a little tricky, since the Finder wants to hide it from us. Just bring up a Finder window, click on Go in the menu-bar, hold down the Option key, and the “Library” entry will appear in the drop-down menu. Click on it, to go to the library folder. Go into “Application Support”, find the “Moog Music Inc.” folder, and delete it.
Here’s what I get after doing that (well, actually from the shell), and starting up the application again:
$ cd Library/Application Support
$ ls -ld Moog*
drwxr-xr-x 3 abc staff 102 Dec 31 18:51 Moog Music Inc.
$ ls -l Moog*/Sub37
total 40
drwxr-xr-x 258 abc staff 8772 Dec 31 19:10 Hardware bank
-rw-r--r-- 1 abc staff 729 Dec 31 18:51 PresetCategories.xml
drwxr-xr-x 4 abc staff 136 Dec 31 18:51 Presets Library
-rw-r--r-- 1 abc staff 4697 Dec 31 19:07 Sub37 Editor Standalone.prefs
-rw-r--r-- 1 abc staff 4132 Dec 31 18:51 Sub37 Editor.prefs
When the editor is started, it says that it needs to get the presets from the Sub37, we say “yes”, it downloads stuff, and woo-hoo! the Hardware Presets column is filled with yummy moogy goodness.
The Categories drop-down appears OK, too.
But since the standalone editor is happy with re-creating missing files and directories, then just wiping out the entire “Moog” directory might be good enough to fix this.
Arg! I’m such an idiot. I forgot that the files that we want to remove are owned by the administrator. I’m not sure how a regular user can delete them. Maybe switch to your admin account and do it from there? Let me play with it some more…
On a slightly different topic: could we have the application just zipped up into a ZIP file? No PKG installers, no admin installations, the user can drag the application where they want it. Oh, never mind… we need the installer for all the other parts: vst, au, etc. Hmm.
Replying to myself:
The fix is to use Finder to delete the your “Library/Application Support/Moog Music Inc.” folder.
Even though it’s owned by the admin who installed it, the Finder is smart enough to ask for permission to delete it.
Once that’s done, run the editor, and things should be fine.