addresses for m158.o. engine objects, like o.granubuf~ and harmonics.shape~, etc

[dappertutto]

@ramagottfried , @equilet suggested i pose this as a question issue: when you were making your o. engines, did you consider giving them their own address spaces? I'm showing students how bundles with lists access the lines~ found in the guts of these engines.

So, for instance, o.granubuf~ would have an argument /granubuf1. Then the packet coming in the left inlet would be preceded by /granubuf1/duration, etc.

The same idea would go for the right inlet of harmonics.shape~, etc.

The reason why I ask is that often students use multiple instances of these engines, and while often they're using the points.phase~ or .buffer~ (or .multi~, @kulpajj 's new version) to drive signal to particular inlets, I also want them to sculpt with packets.

The quick solution i'm thinking of using is just putting in an address as a placeholder and then o.route /granubuf1 before the inlet for the packet.

I hope this is clear. If not, happy to make a patch

[ramagottfried]

hi dave! yes, I thought about embedding a top level o.route in the engines (e.g. /granubuf/rate, /granubuf/bufferindex, ... etc.) but decided against it because when you have more than one of the same type of engine your namespace tends to get bloated (e.g. /granubufs/1/granubuf/rate, /granubufs/1/granubuf/rate, ... ). So by not adding the /granbuf prefix internally, you can then have one /granbuf o.route in your DSP patch, followed by another o.route /1 /2 /3 /4 ... etc. and address them by /granubuf/1/rate, /granubuf/2/rate which seems cleaner.

In regards to the internal line~ objects inside o.granbuf, they are there but I don't recommend sculpting in that way since then you loose all the nice things you can do with timing in the signal domain!

Jon had the same question yesterday, and so I made some patches to make clearer how o.points.buffer~ + phase~ is literally exactly the same as line~ but breaks the performance aspects into in to separate parts. With o.points.buffer~, the main difference is that the time aspect of the gesture is not specified, but requires an incoming phase value to read through the buffer (like wave~) -- this is cool because it allows you to freely move through the gesture in different ways as you like. So the points are like a score, and the phase is the thing that performs the score, could be faster/slower/rubato etc.

Here are the patches: 1) There are some new "points vs line" tabs in the o.points.buffer~ help file: https://github.com/CNMAT/Music-and-Computing/blob/master/help/signal/m158.o.points.buffer~.maxhelp 2) Here is a set of examples on bundle-based sculpting with phase, and sub-phases (for feathered beaming, accelerating/decelerating stuff), in particular see ex 4 which has several gestures controlling different parameters: https://github.com/CNMAT/Music-and-Computing/blob/master/patchers/course/dev/sub-phase-ex/sub-phase-ex.maxpat

and for good measure

3) There's a new tab in the m158.phase~ help patch gives an example of using a second phase~ to create accel/decelerating rhythms: https://github.com/CNMAT/Music-and-Computing/blob/master/help/signal/m158.phase~.maxhelp

hope this helps! rama

[equilet]

@ramagottfried - I think I see @dappertutto 's point here...

There seems to be a discrepancy between the way that addresses are constructed with some of the library's abstractions (e.g., cnmat.o.click.counter~) and others (o.granubuf~). I think we're all interested in consistency, so I wonder if there is anything we can do about this? It's clearly another one of these issues that comes up when we mix libraries. o.granubuf~ was/is something that I believe is meant to be more generic, whereas the cnmat.* abstractions in the M&C library are usually used with o.gui et al.

What's your opinion of this?

[ramagottfried]

@equilet -- sorry, if I'm missing your point, but, what is the discrepancy you're referring to?

[equilet]

----------begin_max5_patcher----------
316.3ocyRF0SCBCD.94xuBReFYvvs47GfO66lESo6bVVokzdcxxx72tzVH5C
Klknl3KTtOtd20O5oDBsV2CVZ58oOkRHmRHj.xCHiwDZKqmKY1PZTE7lttgl
E+DB8X.qy2YXJWs6k2SmgfEmY0s.9pPsaJWw1Xl0M2TMwr3QIDvSDkqUnj.F
515OgZGNQucjFQ3wNHd.nVwNESRyt7aO3jxGY78vvDuYrDcLj6mwmM.GiUop
nHuHKsb8hvxxPz744Eoa764bRh+Q1OSWbUKCy04bofuOmqcJDLWi4leklq52
zbequJWDMzp3R4h+Be8kqWWPJk+iuNMpmoqSEUWTOgJPYccG.iUnUAC48yfc
ZzFe3prPnPECC+foF3fXJ+v4fxLCS.NzdmIZh96VRiaUuELJmvSKS7c9bxG.
a.g+1B
-----------end_max5_patcher-----------

[ramagottfried]

ah, so you mean that some objects have an existing namespace, and some require you to specify your own namespace.

It seems pretty clear to me that "wrappers/engines" will have their own namespaces and "tools" are things that you use to move ideas between input and output wrappers.

[equilet]

The issue is that it's not clear to the teachers, and the discrepancy remains.

[ramagottfried]

how can we make it more clear?

[equilet]

I'm considering the same as well - how do we designate "tools" vs. "engines/wrappers"... Maybe @dappertutto or @kulpajj have some ideas on this... They'll wake up soon enough. :)

[ramagottfried]

I don't think it's a "discrepancy", there is consistency -- but there is a difference in the way these tools are used.

[equilet]

There's certainly consistency within the disparate elements of the two groups that illustrate a discrepancy. :)

Hmmm... designating a namespace is pretty standard practice, and I think it'd be interesting to remove the differences in the requirements for such a thing on the part of the user (students), which as it turns out, is based on the way that things are architected in the m'n'c library. I'm not sure I even understand the differences between a wrapper and a tool in this case. For ex., o.granubuf is a wrapper in my mind, but you're saying above (I think) that it does not require a namespace.

[ramagottfried]

no, I'm saying that engines like granubuf~, filters~, res-transform, or wrappers like o.io.b2k, etc. are processes that have many parameters, and usually have their own namespace. Whereas with tools that are used more in the middle or processes it's nice to have more flexibility in creating the namespace.

[equilet]

but the example given by @dappertutto in his initial post was o.granubuf~, which doesn't require a typed namespace (as an argument to the abstraction)

[ramagottfried]

my understanding was that @dappertutto 's question was about whether there should be an internal /granubuf prefix.

but, ah! I think I misunderstood one point about that, @dappertutto why didn't you correct me?!

I see now his question was whether a prefix could be assigned as an argument -- for sure, that's a great idea.

[equilet]

I think that a thread like this will undoubtedly help us categorize an overview correctly. :)

[ramagottfried]

@equilet I thought your point was broader, that the namespace should be completely user-definable. (which I'm sympathetic to)

[equilet]

nope

[dappertutto]

Glad its clear now! Rama, if I remember correctly, you worried that address spaces for the engines/wrappers (o.granubuf~, m158.o.harmonics.shape~, etc) would perhaps cause too much verbosity. This might be true, but its best the students deal with that.

[ramagottfried]

cool — yeah, my worry was that if the internal namespace was prefixed, it would a lot of extra /names — but if it’s user assignable then each one can be unique which solves the problem, neat!

I’ll try to implement that soon — sorry I didn’t understand at first — please correct me next time! otherwise I may never have understood : )

[dappertutto]

heh, well in order for me to have done that I would've had to understand that you misunderstood ;-) . I don't feel passionately enough about this stuff yet to push my viewpoint. hey, where can i get a hold of the beta versions of the cnmat.resonators and cnmat.transform? Not that i'll try to implement them this semester, but curious...

[kulpajj]

I am not personally too opinionated on this one but I think that for objects that do have required /names, the help files should just draw the eye to that fact through a bold header OSC Required Namespace, or whatever. I'm not in front of my computer, and I know you do list address spaces in the help files but I would just say make a macro category in bold that is consistent in the help files. Or if there wouldn't be required /names, the help file also list that very fact directly.

On Thu, Oct 19, 2017 at 7:39 AM David Coll notifications@github.com wrote:

heh, well in order for me to have done that I would've had to understand that you misunderstood ;-) . I don't feel passionately enough about this stuff yet! hey, where can i get a hold of the beta versions of the cnmat.resonators and cnmat.transform? Not that i'll try to implement them this semester, but curious...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/CNMAT/Music-and-Computing/issues/76#issuecomment-337929011, or mute the thread https://github.com/notifications/unsubscribe-auth/AWhttSRUbU77xul_4LHOgAdfqlSRcmYdks5st18SgaJpZM4PvtEH .