Very interesting, congrats, and thanks for sharing. What are the major advantages to running something like this as opposed to running a simple Unreal Engine scene?
It is a great start, congrats on the release. Out of all the categories offered, I'm missing "Invertory" category. A place where I could ask AI to remember something and to retrieve it later on. For example :) "Honey, where do keep the measuring tape?" - "Living room, white chest, first drawer.". That's what I'm missing in my life. On the other hand, all of my contacts originate from the phone address book, so unless there is some special synchronization, I don't see how I would manage them in Ontoplano.
I implemented inventory management in /shopping: I hated crossing shopping lists in the market and having to think about it all again later. Much better to keep a pre-determined list of stuff you want to always have at home (with the option to snooze it if you are not feeling like buying that for now, but may be in the future) and only say if you do have it or if you need to buy it.
But you're asking to have a list of non-consumable stuff you have being able to record where it lives; I'd just use shopping, mark as something that I have, and put it's location on the description. You could create a category there: "House stuff" or something.
The challenge with an inventory, as opposed to shopping is classification. With shopping lists, I don't need much classification, milk is milk, lettuce is lettuce. But, for an inventory, I need a tree of parent-child relationships as well as tags, with freely configurable destination fields, like, for example, KeePassXC/KeePassDX. Not all objects have same data attributes, like, for example, that measuring tape, is it a 3m or 5m tape, is it a construction tape or tailor tape. My USB cables in the drawer, are they USB2 or USB3, USB-C or USB-A. In my brain, a shopping list is a flat array, while home inventory is a file system with tags.
Makes sense. I will put that on the ROADMAP, maybe /shopping can be reworked into /inventory and made way more detailed and powerful. Thanks a lot for your input!
It can run from any path so long as your plugin host or DAW is happy to load it from there (the plugin APIs define standard folders plugins should be installed to, but lots of host allow other paths).
That's unfortunate. That means that in a multi room studio synchronization can't happen and each instance will drift and has to be set again and again. Here's a way how to resolve this (as implemented by Surge XT or any of the U-He): the software should infer its own runtime path and then test for the existence of a subdirectory "data" (for example). If the directory doesn't exist, then settings files are read and written to operating system's well known paths. But, if the directory does exist then all runtime files should be read and written from there.
Interesting, I'll take a look at the Surge source, they're a clever bunch. If you have a moment - I'd like to understand this use-case more. What do you mean multi room studio? Does a per-user installation help, vs an all-users installation?
Historically, early VST plug-ins were fully portable. They were rarely communicating with the underlying file system and were leaving all state management to the host. This made a DAW and a VST library a single unit which could run from anywhere, including network attached shared drives. So, in a multi room studio of yesteryear or in a distributed band studio of modern times, only one setup was needed for all of the nodes. A studio engineer would prepare a DAW+VST directory, share it via network, and all studios would have exactly the same setup with exactly the same plug-ins, with exactly the same configuration without having to repeat the whole setup N times. Therefore, a musician/producer/engineer could work in any studio room without limitations or distractions. The leader in this field is Cockos Reaper which supports fully portable operation, plus full relative path expansion everywhere. In my experience, there are about ~3000 VST2/VST3/CLAP plug-ins in existence, running flawlessly for decades now. So, by saving the plug-in state to operating system's semi-hardcoded directories, your plugin stays non-portable, and instead of being a full part of the DAW setup, becomes an unmanageable mess that nobody wants to deal with.
Interesting! Thank you for the explanation. I wonder what file permission issues we might face trying to write adjacent to the plugin file. I'll see what Surge does.
Sure. Just make sure to bubble the error up to the UI and no problemo. Recent portable software even includes a toggle in settings to dynamically let users decide which state store to use, like, for example, the excellent LinkLever.
reply