Whilst it isn’t 100% necessary (conceptually) to give the name in each audio/scheduler object (the name doesn’t change the number of inlets/outlets only ithe non-realtime status does that), there are significant issues with not doing so (mostly to do with the difficultly of tracing connections upwards).
So the questions are these!
What should be the way of giving a context name in the box?
What should be the way of setting realtime/non-realtime?
The “nrt” tag was just a quick thing for now, but I’d like something that seems sensible/fits the style of other things. It maybe shouldn’t be a “/context name” because arguably it is not a framelib parameter.
Anyway - thoughts please and I’ll code something up. Having named contexts will allow you:
to make non-realtime contexts that can be triggered separately/don’t interfere
to control multithreading on separate contexts (realtime or non-realtime)
Where string is the identifier for the context and realtime can be true/false or 1/0.
I sort of get this, but not 100% - perhaps you can expand on your reasoning here. To a user, its something they configure so it seems suitable to be configured via a parameter IMO.
The context name and realtimeness are not known about directly by the actual framelib object. They are max only settings (they might also apply to pd). They wouldn’t turn up on helpfiles / info etc. etc. So it’s a slightly different thing.
Note also that you’ll be using the context name and realtime status in all relevant boxes (schedulers and audio IO).
Can the names not be implicit by some sort of logic? Like, this patch has fl.context~ in it and so everything inside the patch is now a context - no matter what?
Yes and no. Contexts don’t need names (so in a patch there are 2 implicit contexts - one realtime and one non-realtime). What we are discussing now is:
1 - how to choose the realtime or non-realtime context for relevant objects
2 - how to give contexts names so you can control them separately
Okay, so you are saying my answer before is not a good solution because its not the context you are referring to but the objects? I’m a little confused. To me the obvious solution is you have a context and all the objects pertaining to that context can be realtime on or off. You differentitate contexts by name or patcher - so you could have two names inside two separate patchers that share a context. In a sense, I imagine the fl.context~ object acting as an advanced interface for a patcher and every child patcher and can create sweeping changes to objects through that kind of relationship. I profusely disagree with the idea of putting the context or real-time ness in every desired object.
As outlined in the thread above it is necessary for all objects without audio IO (source/sink etc.) and all schedulers to explicitly state their context. If I adopt the concept of named contexts (which have certain advantages/flexibility) that means all these objects must state the context name (although this could be blank to use the default context name of “”) and realtime or non-realtime status (here realtime will be default if nothing is requested).
Other objects in a a network will take care of themselves.
The above is currently non-negotiable, no matter how strong anyone’s feelings are because there is already some quite heavy lifting behind the scenes to make context-switching work at all. There are technical and conceptual problems posed by the idea of just stating these things in one place that I am not confident that I can solve adequately, elegantly or possibly at all (I won’t go into why because it is too lengthy and involved and it won’t make anything clearer to attempt to explain it in text).
Please don’t think primarly about the fl.context~ object at the moment - you are imagining it somewhat differently to the way it current works, and probably how it will work in the future, if it continues to exist under that name at all. Please also forget the idea that you put a fl.context~ in a patch and all other objects magically know about it - that is problematic for three reasons (when I can know it exists/issues of conflicting fl.context~ objects/you should be able to have two contexts side-by-side in a patch and this wouldn’t allow that).
So - I’ll attempt another explanation. Audio/scheduler objects need to state or determine their context (from which other connected objects figure out which context they are in). These items are not parameters of the underlying framelib object, but only the max object hosting it. I am looking for a notational way that you type these two items into the object box.
I realise this stuff is a bit hard to get your head around so thanks for continuing to try and understand it If this explanation is still unclear then I think further discussion would be better done in person, as diagramming etc. would probably help.
No, your explanation is fine. It is confusing because fl.context~ and nrt were delivered in a build to me around the same time and so when you talk about contexts my mind goes to contexts, threading and NRT in relation to that object.
Given that fl.context~ doesn’t have the place I think it does in this stuff it makes sense to have a simple and clear parameter for both things.
seeing as you have to apply these parameters to every object sane defaults would apply (so that making patches would exist how it does now) but stepping out into context management and NRT stuff makes the user specify /realtime 0.
OK - so you prefer the “/param” notation and to not have to understand the distinction? Should there report in the info.
Also - there’s just one thing I don’t seem to have got across. You don’t set on ALL objects (you would never set on an fl.random~ for instance). You only set on schedulers and objects with signal/audio inlets and outlets. If you have the latest build from this branch and look at the examples it is the same objects you would need to specify “nrt” on.
Okay, I hadn’t checked out that build till now. Honestly, I missed the post and didn’t see it.
I much prefer how the second demonstration of new features looks except as per my post above some kind of parameter notation would be preferable than to nrt as the first thing in a box. Another option is maybe another kind of special notation - I feel like the feature is becoming large enough to warrant it possibly… Streaming has =, parameters have / so something like # might work.
OK - so I’ve now added named contexts. The same link takes you to this version now:
This currently works like this:
#nrt 1 (for non-realtime or omit for realtime or set #nrt 0) #id (to set the name of a context - or omit for the default “” name)
These are valid on any fl. object, but you need to set #nrt when required on all schedulers and audio objects (as before). Names will propagate more throughly, so these can just be set on schedulers in order to put a network in a named context. fl.context~ then requires the same to set which context it is controlling/representing.
I’m not a massive fan of the # (having used it previously for all of frame lib parameters, it now looks clumsy), so I’m open to suggestions. I’m not aware of any max objects with attributes that can only be set in the box, but this is another possibility (@nrt / @id) if there is a precedent for it.
Thoughts and testing please - I intend to bug fix (if necessary), tweak and then roll this all into master quite soon.
1 - So you can run different non-realtime networks at different times (otherwise disconnected networks in the same context patch will run at the same time)
2 - to control multi-threading separately for different realtime networks.
I have to say I agree re: # even though I suggested it . I think using @ is dangerous conceptually though so perhaps its about finding the right kind of symbol or method for configuring it that distinguishes it from parameters, but makes it feel like a FrameLib thing.
If I use @ then I’ll implement it as a true attribute, but these aren’t things you are allowed to change after making the objects at the moment, so that could be a problem. If someone knows of a standard object with an instantiation only attribute I’d be interested to know about it.
. I think using