search

CNMAT / CNMAT-odot

Multi-paradigm Dynamic Programming
Other
115 stars 11 forks source link

file preferences; user notification for /dev & /deprecated #402

Closed andrewh closed 3 years ago

andrewh commented 4 years ago

On the 1.3 release, when loading o.overview.maxpat, the console prints an error, e.g.

newobj: o.downcast: No such object
script connect: can't make connection (docmsg 0 -> obj 0)
script connect: can't make connection (obj 0 -> oroute 0)

I fixed this by adding the Packages directory to my list of paths in File Preferences.

equilet commented 4 years ago

I fixed this by adding the Packages directory to my list of paths in File Preferences.

This should not be necessary. The instructions in o.overview (found in the extras menu) should cover the situation of adding dev/deprecated. Can you please read the text there and let us know whether or not this fixes your issue? Please do not add the Packages directory as that can cause unwanted conflicts.

equilet commented 4 years ago

see [p dev] and [p deprecated] in the aforementioned patcher

andrewh commented 4 years ago

Thanks, that's fixed now. I remember doing this in the past, I just forgot. I suppose the errors in the console might freak out some new users. Maybe using [filepath] in the relevant patch ([o.autodoc_overview]?) this could be hidden?

equilet commented 4 years ago

filepath won't work albeit for the current session, unfortunately. I might ping someone at cycling about this because it's killing us.

equilet commented 4 years ago

The text in the o.overview states clearly that we are not responsible for any mayhem that ensues due to a user enabling the /dev and /deprecated folders, and that they are subject to change at any time. I think this is sufficient, but not very easy to find (still!!) when installing. I personally feel that adding something in the package manager and to the main README might help us a bit. @andrewh do you have an opinion on that?

equilet commented 4 years ago

worth mentioning for anyone else following that this all pertains to the tutorial branch for the time being.

andrewh commented 4 years ago

filepath won't work albeit for the current session, unfortunately. I might ping someone at cycling about this because it's killing us.

I suppose I meant to try to detect the presence of the directory (regexp) in the search path, and if not don't fire the script. This might work per-session. Horrible though :)

The text in the o.overview states clearly that we are not responsible for any mayhem that ensues due to a user enabling the /dev and /deprecated folders, and that they are subject to change at any time. I think this is sufficient, but not very easy to find (still!!) when installing. I personally feel that adding something in the package manager and to the main README might help us a bit. @andrewh do you have an opinion on that?

Maybe just moving [p dev] and [p deprecated] out of the overview patch would be enough. The warnings can remain in those patches, and maybe mention them in the README as optional extras.

equilet commented 4 years ago

I definitely think they should stay there, but should maybe also live in these other areas. Will discuss.

equilet commented 4 years ago

I suppose I meant to try to detect the presence of the directory (regexp) in the search path, and if not don't fire the script. This might work per-session. Horrible though :)

Yeah; I tried something like this and it wasn't satisfying.

adrianfreed commented 4 years ago

Have you all considered throwing the /dev and /depracated stuff into the release and putting the warnings in the help patches and object load time max window messages?

The development context that produced those folders in the first place no longer exists. At the time the idea was to quickly update the release with new solutions to the depracated stuff we depended on and finish the experiments associated with the /dev stuff. All this to not delay that first release and buy us some time to get the rest sorted. It didn’t work out that way and now there are deep dependencies in a lot of patches on some of that stuff.

My best understanding of the current context is that there hasn’t been any new development - there has been welcome documentation and bugfixes and updates as Max and the OS’s change but not much in the way of new features or externals or language. There likely will be no o.dot 2.0 and the external community has taken up using odot somewhat but for the most part is not investing in developing it.

Also, I can’t see the advantage in trying to nuance what people might expect support for or not when the somewhat bleak future looks like there isn’t going to be much in the way of institutional support. I can’t speak for CNMAT but I did get confirmation that there isn’t any interest from Cycling74 like we used to have in the early days where they integrated a lot of our externals into the product core. They are actively working in the other direction in fact (pushing some of their internal things out to the community to support and develop).

On Sep 11, 2020, at 09:25, Jeffrey Lubow notifications@github.com wrote:

The text in the o.overview states clearly that we are not responsible for any mayhem that ensues due to a user enabling the /dev and /deprecated folders, and that they are subject to change at any time. I think this is sufficient, but not very easy to find (still!!) when installing. I personally feel that adding something in the package manager and to the main README might help us a bit. @andrewh do you have an opinion on that?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.