ramagottfried
commented
6 years ago also, probably o.gui should be o.io.gui, and should replace the o.demo.maxcontrols in the main odot release...
Open ramagottfried opened 6 years ago
ramagottfried
commented
6 years ago also, probably o.gui should be o.io.gui, and should replace the o.demo.maxcontrols in the main odot release...
ramagottfried
commented
6 years ago or o.io.gui should stay with the other o.io wrappers and we just remove the o.demo.maxcontrols since it's pretty old and not as developed
EdmundCampion
commented
6 years ago I think the idea is to migrate wrappers out of the current o.io repo/project and into the release package one at a time, as there are aspects of the o.io that were researched or pending but never brought for use. ?
ramagottfried
commented
6 years ago ah right, I should review the original o.io repository -- but I was referring to the m158.o.io wrappers which were adapted from the old o.io materials.
equilet
commented
6 years ago I'm not sure that o.io.gui is generic enough to be in this categorization, until we can test and prove that it works in every single case with any o.io UI object as well as every Max UI object. Right now, I feel that there is much work to be done with it to be that generalized. As such, we could put it in /dev or /experimental (but in which repository?).
Some thoughts:
o.io are we using that we depend on in courses (production ready)?o.io...o.io that we're interested in? How does it pertain to situations OUTSIDE of the M&C course? I'm thinking about things like o.io.leap, etc.o.io.leap is used in productions that have nothing to do with computer music, but more general media programming, and is meant to be a generic tool. I would see it going into CNMAT-odot, if anything.o.io and CNMAT-odot ?equilet
commented
6 years ago Also worth mentioning that there is a fairly large problem with the naming of a lot of these things. For example, o.random is not specific. What type of randomness? uniform? We have that in the odot distribution. Uniform based on timestamps that are unique? How do we clarify what that is in the name, etc...
I'm not trying to be argumentative here, but I see a certain over-generalization in the attempts at making tools that are accessible and immediate for the course vs tools that are general and well-oiled enough to put into the odot release, no? I'm also concerned about compatibility. A lot of the stuff that was built in the course was built with the idea that these patchers would be put together to form "engines", and as such I'm curious if it's worth it to keep the relevant materials together. Again, just trying to evaluate which cases we should keep things here vs. moving per your original request (thanks for bringing this up, BTW; I think it's critical).
There are certainly exceptions to this (lots of o.* stuff in the M&C package that I find generally useful), but then we have a couple of other problems:
cnmat.loadbang, which is now, just a simple loadbang. It doesn't function any different from the Max loadbang, although there are features that we might want to add to it (like an init receive, for ex.) which could be useful. But where does that tool go?equilet
commented
6 years ago I prefer o.io.maxcontrols to o.io.gui. I just find it far more intuitive and easy to work with for making static presets. I've not seen any examples of interpolation with o.gui... Has anyone made any?
ramagottfried
commented
6 years ago hi @equilet, thanks for your many probing thoughts!
ok... this is a long one, better get yourself a coffee and a comfortable chair!
Should we combine o.io and CNMAT-odot ?
Having just typed out lots of responses, I think now that o.io should be separate from the main odot release since many wrappers require third party objects.
Possibly the mouse and keyboard wrappers could be moved (or even duplicated) into the odot release as examples of the o.io wrapper model which I think is super useful to understanding the power of odot.
Do we really want the "release package" of music and computing, which is essentially a container for learning electronic music, to contain tools that are not necessarily used for this purpose?
The idea is that the Music/Computing package basically replaces the Depot, where there are teaching materials but also provides a highly flexible set of tools for producing new work. The courses teach how to use the materials, but the tools are independent from the course.
The o.io.wrappers that we made for the class were cherry-picked from the original o.io repository, and used as the central tools for M158B, so in my mind o.io is now a core aspect of the instrument design tools.
I'm not sure that Music & Computing or Composing & Coding are fully descriptive names for the package...
e.g., o.io.leap is used in productions that have nothing to do with computer music, but more general media programming, and is meant to be a generic tool. I would see it going into CNMAT-odot, if anything.
I don't think we need to worry about "computer music" vs "media programming".
o.io.leap is an interesting example -- I think it should be released if you think it's ready! It requires some extra libraries and you need the Leap application to be installed, and a special developers contract if I remember correctly. So I'm hesitant about including it in the main odot release, but it would be a nice addition to our collection of o.io wrappers (there was a student last year who asked about it also).
At the moment we are including the s2m.wacom objects and the cv.jit.contours object to support the m158.o.io wrappers, and we definitely should include the o.io.leap if you're up for it.
I'll make a new issue about externals in the M&C repository.
The s2m.wacom objects are getting old now, and I had thought about maybe making a o.io.wacom at some point also...
So: specifically only in regard to the o.io m158B wrappers currently in the patches/io folder, are you in agreement that we can name them o.io instead of cnmat.o.io?
Also worth mentioning that there is a fairly large problem with the naming of a lot of these things. For example, o.random is not specific.
I'd call that a fairly normal sized problem : )
What type of randomness? uniform?
yes (pseudo random)
It's an adaptation of the C library's rand() function: http://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/random_r.c;hb=glibc-2.15#l361
We have that in the odot distribution.
I know, but o.uniform is just the max random object scaled 0-1.
o.random is an example of how to program the rand() algorithm in odot. Probably it should replace o.uniform.
Uniform based on timestamps that are unique?
The time stamps are for seeding the rand() algorithm, like srand() does.
How do we clarify what that is in the name, etc...
I agree that the name could be improved (even though it's the approximately the same as the C library and the max object "random").
I'm not trying to be argumentative here, but I see a certain over-generalization in the attempts at making tools that are accessible and immediate for the course vs tools that are general and well-oiled enough to put into the odot release, no?
I think the tools we give students (and non-students) should be well thought out and carefully designed so that they are encouraged to use them in their own way. Too many times have I seen patches that were made as pedagogical examples just get re-used thoughtlessly.
I think not giving the best flexible, general tools we can is a dumbing down and creates limitations for everyone.
The danger is rather in under-generalizing.
well-oiled enough to put into the odot release, no?
You seem to have a very high regard for the patches in the odot release! : )
As I mention above, I now think that we should not move the o.io wrappers into the main odot release.
I also think things like the experimental aspect oriented research should probably be in a separate folder and presented in context with the ICMC paper, maybe moved to the research repository.
What objects, patches, ideas in o.io are we using that we depend on in courses (production ready)?
Here's a brief status of what's in the M&C io folder:
I'm also concerned about compatibility. A lot of the stuff that was built in the course was built with the idea that these patchers would be put together to form "engines", and as such I'm curious if it's worth it to keep the relevant materials together.
yes, agreed. Probably they should all stay together.
Again, just trying to evaluate which cases we should keep things here vs. moving per your original request (thanks for bringing this up, BTW; I think it's critical).
Ok, yes, so we seem to be moving towards not moving anything into odot except maybe the mouse and keyboard wrappers and maybe some of the o.random stuff?
There are certainly exceptions to this (lots of o.* stuff in the M&C package that I find generally useful), but then we have a couple of other problems:
The course was developed with this fairly esoteric scaffolding that allows the /doc message to be input, and no other objects including in the odot package do this. Should we now change all of the objects?
no! we should not change all the objects. I think I have never once used the doc functionality -- the main interesting design point is that the m158 abstractions always pass the full bundle out.
Change the patchers?
no! that's pretty extreme!
It might be interesting to make a list of abstractions that you actually use from odot.
For example, I don't like o.was -- I prefer to use /prev.
Most of the M&C patchers include something that is now called cnmat.loadbang, which is now, just a simple loadbang. It doesn't function any different from the Max loadbang, although there are features that we might want to add to it (like an init receive, for ex.) which could be useful. But where does that tool go?
definitely not in odot! it should stay where it is.
The loadbang still has issues when initializing after copy pasting, but having it as an abstraction gives us the ability to try to fix it somehow.
In regards to the broader o.io collection, I agree that wrapping the max GUI is a unique case, since it's internal to the program it's not a hardware io -- but a wrapper for the screen-based UI within max.
I'm not sure that o.io.gui is generic enough to be in this categorization,
I'm not sure what you mean by "generic enough to be in this categorization", what does the "io" categorization mean to you?
until we can test and prove that it works in every single case with any o.io UI object as well as every Max UI object.
It uses pattr so de facto it works with all Max UI objects.
But, what do you mean "with any o.io UI object"? ... ah, I think you mean bpatchers, like your BCF UI patch... I see... that seems like an easy thing to implement, are there non pattr-able GUI o.io objects?
Right now, I feel that there is much work to be done with it to be that generalized. As such, we could put it in /dev or /experimental (but in which repository?).
While I agree that the o.gui system is young and could use more stress testing -- the main, central, focused core, of the o.gui idea is that the max GUI should be avoided as much as possible : ) -- and reserved for top level controls.
After teaching M158 over the years, I grew wary of seeing students constantly using GUI objects in the inner mechanics of their patches, which as you know is a bad idea for reasons of threading and also tends to create hidden state problems. Working on the io wrappers made me realize how elegant the design is, and that we could try to use something like this to avoid the trappings of typical max spaghetti error prone patching.
However, yes: it was designed primarily a pedagogical device. I use GUI objects very sparingly in my production patches -- for most cases I'd say o.gui is as production ready as pattrstorage is : )
let's schedule a meeting to discuss.
@equilet @EdmundCampion
I think the 158B wrappers are ready to be o.io instead of cnmat.o.io now.
This also makes me wonder if we should move the o.io wrappers into the odot repository?
Or maybe it makes sense to keep it in the Music-and-Computing package?
There are also a few other o. abstractions in the Music-and-Computing that could be moved to odot, like o.random o.random.weighted, o.ntom, ... but on the other hand maybe keeping the abstractions mostly separated makes the odot package a little more refined.