search

cac-t-u-s / om-sharp-users

A public forum for support / issues / suggestions about OM#
3 stars 0 forks source link

Workspace-like features #5

Open geofholbrook opened 4 years ago

geofholbrook commented 4 years ago

What's your intention for assigning preferences to specific projects? I was thinking about how "workspaces" work in VS code ... the software gives you access to the file system in the GUI, starting at the root of the current workspace, but it's transparent (nothing hidden like an "elements" folder). Any vscode-specific configuration for a workspace is in a .vscode folder. Would it be appropriate to have something similar for om-sharp ... like a .om# folder? Is that going backwards with regards to eliminating workspaces?

geofholbrook commented 4 years ago

from email thread [edited]:

That was part of the plan initially. I wanted to allow both opening files freely and at some point, consolidating a kind of workspace. There is even a om-workspace.lisp in the OM# kernel sources, which at the moment is nothing more than a simplified version of the OM code. I just had no time to do it. Using a .xxx transparently in an existing folder, rather than embedding stuff in a dedicate folder is a good idea. If we're doing it, we must also think about simplification of file dependencies: patches using patches, or other resources (audio, MIDI) : a workspace should free users from thinking about it: once a resource is in the workspace, it should just be available. To me this is the main and almost only interest of using a workspace. Per-project preferences is another thing, but in my experience from OM, users prefer to have the same settings across workspaces.

Actually there's another reason why I didn't do the workspace eventually in OM# — or maybe, why did not prioritize it as a "must-have" feature, which is that I ended up liking and trying to keep OM# "kernel" way simpler than the OM kernel used to be. This is (in a significant part) due to the fact that I got rid of the workspace. I like to think that (in the OM# kernel) we are "just" doing visual Lisp programs, and am also thinking in questions like maintenance in the future, etc.

geofholbrook commented 4 years ago

You are right, kernel is smaller ... 28k lines of code vs. the previous 46k! More significantly, a better organized and clear file/folder structure, I guess that's what comes from rebuilding :)

geofholbrook commented 4 years ago

Workspace-specific preferences: I can go along with your opinion on that one. Scanning the preference panes I see that many of the options available pertain to editing, creating boxes and patches etc. so wouldn't affect the operation of an existing patch or 'workspace'.

File dependencies: here you're talking about that space between writing a library and using patches ... which also includes resources as you say, audio, midi, sdif, etc. Funnily enough the previous workspace model didn't really give you instant accessibility, not in the sense that you could type the name of an abstraction to use it in a patch. Is that what you have in mind by" accessible, period"? I think it would be excellent. But it would require some notion of what is the "root" folder in order to know how far up the file structure to search ... also a way of dealing with duplicate file names.

I see you already have a new preference: "Main search path". Seems the purpose of that is to deal with loading patches that already have abstractions in them. Would a quick approach be to apply the same logic when you type in a .opat file name for a new box?

j-bresson commented 4 years ago

It is the case already, yes. if you create an abstraction with 'p' you the search patch is the folder the "base" patch is is in, plus the one specified in prefereneces. https://cac-t-u-s.github.io/om-sharp/pages/abstraction#global-abstraction

geofholbrook commented 4 years ago

Ok I see, this was broken. See PR cac-t-u-s/om-sharp#145

j-bresson commented 4 years ago

So this is fixed now. As a remaining question, we can thing of additional desirable workspace-like features, and whether they are worth adding. I do think the access to resources like Audio/SDIF files could be improved, so you don't systematically have a red-error displayed on the sound box. I could think of the following improvements:

j-bresson commented 4 years ago

ps. I'm creating Issues about search-paths in cac-t-u-s/om-sharp#152 and cac-t-u-s/om-sharp#153.