A couple of users had a discussion about what would be the "best practice" of updating community library objects, without breaking patches that uses those objects.
Here are a few things I noticed that could potentially break patches:
1 If you for example use an object from com.lib. with an inlet named "in" and you rename that inlet to "in1", all cables that was connected to the inlet will be lost. This can be pretty cruel if you have some advanced patches.
2 Also adding new parameters can have an impact on older patches.
3 Renaming objects will also make the object in a patch loose all its settings. Settings are important.
Anyway, this is my introduction to the topic.
What do you think?
What would be a good set of, not rules, but guidelines of how to update objects without breaking patches?
Bit outside the square here, I asked myself this the other day, and wondered could the best way to avoid a patch requiring use of the latest lib objects is to embed them into the patch when you first create it. Then this way the patch will always stay the way it is, and any updates to objects into patches can be done case by case. If this is the best way, then maybe all patches should automatically embed all its objects. The obvious disadvantage of this is changes to the firmware or axo gui could cause older objects to fail. Just a thought !
currently there is a 'workaround' you can embed objects into patches, if you need it to be stable. (its not ideal, so again see lifecycle thread for proposals on better methods)
are (2) and (3) correct? , they seem like bugs to me if they are...
generally in development, developers try to avoid changing the interface, or the 'external behaviour', in axoloti this would mean:
changing behaviour i.e. what the object does
renaming inlets/outlet*
deleting inlets/outlets*
renaming parameters/attributes ( since init/preset values are lost) (deleting parameters/attributes is very likely to break, as its hard to see how you can do this without changing behaviour
(* caveat, only if the user has connected them in their patch)
usually extending an interface is considered reasonable... for axoloti this would mean: - adding new parameters, attributes, inlets/outlets - adding optional extended/behaviour
the basic idea is simple, an object basic behaviour should not be radically changed (if it it you create a new object with a new identity) ... but it often is extended.
the reality is software can be 'fragile' meaning patches can be broken by even subtle changes to behaviour, e.g. its not unknown for 'users' to code a patch up, and for it to be broken since an object has a 'bug fixed'... i.e the user was inadvertently relying on a bug.
one thing Id personally not want, is lots of 'versioned' objects, with subtle differences... e.g. GreatObjectV1 GreatObjectV2 GreatObjectV3
the issue, there is no way for us to ever remove GreatObjectV1 from the library, so our library will be polluted with objects that are not used (all new users will of course of for GreatObjectV3), and they will be difficult to filter in the Object browser ... again the lifecycle thread on this. also its unnecessary, we host the library on GitHub which is a version control system i.e. it holds every edit ever made to the object.
I dont think it should be 'automatic', as many times you want the most up to date version.
BUT this is basically one suggestion Ive made previously. that we could have a 'lock patch' option which embeds all objects (perhaps giving the option of community only)
however, what I also want to do with this is add an 'unlock' option, both for the whole patch and individual. to do this, I need to add the a new field to the embedded object, to hole the UUID of the original object. (subpatches need to be done a bit different)
Ive also suggested in the lifecycle thread a more elaborate version. this uses the git repository, so you can go 'back in time' for objects, and then embed or not. (it needs a bit of visual work to, so that the user can easily see what objects are subject to 'upgrading' etc)
I suppose the solution really is two parts a) education ... so contributors know whats breaks patches (though I suspect most do already) b) technical ... the above, we have a way in axoloti to 'manage change'
Could you simply have a way of stamping an object or patch with the firmware version number and or gui version number so it is easily identifiable which environment it was created under ? Maybe the gui could have a way of recognizing if an object has a different version number and make it highlighted someway, that way users can be clear that they have selected an out of date object / patch etc..
My personal approach is also embedding objects OR copying them form the com.lib to my own library.
About subpatches. I think there are som issues with subpatches. I mean .axs. When I open a patch more than often subpatches comes up as "red" and cant be loaded. When I reload it form the same location in the library, it will have lost its settings! Why I dont really understand. I do the same as I always have done, but again it have happened since the start, so no news here! So basicly using subpatches as .axs dont work very well. I HAVE to make them embedded for them to work everytime. Working every 2. time is no good, cause when you have spend hours dialingin setting you would want to have those setting when you open a patch again.
Yes they are correct. 2: if you add a new parameter, which has got another default value that you use in the patch...... that setting will have an impact on the sound of the object.
3: Cant give an exact example as for 2, but I have experienced this. Will see if I can dig an example up.
But I think that we should be able to "trust" the comlib objects, to not change too much.
Yes, that is what I wrote, not rules, but guidelines!
Sorry I dont think this is a great solution.
Yeah, I understand..... But that doesnt apply to THIS forum, cause it happens and it will happen again and again. So I dont think this helps anyone to be honest.
I am confident that this could potentially make you, @johannes loose customers; if they cant really trust objects from comlib, they will loose interest in Axoloti... To unstable to use... And lets be honest.. there are many small unstable things in Axoloti, if not unstable then really hard to learn. So..... First very steap learning curve and then a community library that changes with no regards of users patches...... erhmmmm...... I have several friends who have sold theirs again cause of problems like this. Sooo, if people who are not as deep into Axoloti as me, TB, Gavin, etc. and know it as well as we do, they WILL loose interest if they dont have a stable platform!
Seriously. Look ath the forum today. There are atleast a couple of thousand Axolotis out there... And it is the same core users people writting almost very post in here.. This is food for developers thoughts!
Well I would rather have this, than patches breaking all the time! To me reliability is more important than how the comlib is looks!
And that is why I suggested this thread, som we atleast could have a discussion about it.
Anyway, I guess after reading some posts in this thread my conclusion for now is:
Don't trust the community library!
Which I think is a pitty and not exactly what a developer would want!
If you/the community create a 'best practices' post in the user-guide section, then I will then make a wiki post, so anyone can update. (you should be able to create this directly in user-guide, if not post it anywhere, PM me and I will move it)
Id suggest the post should also explain why each guideline exists, so new users can understand the basis... i.e. rather than saying it breaks patches, say why... so they learn about the impact.
p.s. Im assuming there will be no 'enforcement' or comments to contributors about not following guidelines. we don't want users feeling they are obliged to follow the guidelines. its merely suggestions about best practices
It's not an easy problem. There's a benefit in quick and easy sharing of objects and patches, avoiding the need to download, unzip, copy to the right place, etc. Sharing an object implies others can build on top of that, and perhaps discover and report issues. Without such exposure, issues will not get discovered. If something needs to be fixed, it better gets fixed otherwise we'd get the same issue re-reported after it is fixed. But sometimes the line between fixing and (unwanted) behavioral changes is very thin. If objects are duplicated, for instance embedded in a patch, fixes do not propagate. If a referenced object in a patch somehow is different (if its kept from upgrading) from the one in the library, it could cause deep confusion because the behavior could differ for no apparent reason.
Not everyone is a forum poster. When I was using the Nord or Pd or Max I hardly posted to those mailinglists or forums.
I do take your comments to heart.
@Gavin the gui version number is in patch and object files, but this is not very indicative of relevant changes.
Hard to avoid, there needs to be some sort of reference in a patch file to restore connections from. If it would be the index of an inlet rather than the name, the risk of restoring an unintended connection is larger when the inlets are modified, which I believe is worse.
I'm confused here: adding a new parameter implies that the parent patch does not have it yet (and the parent patch will take the default value).
Do you mean renaming an object in a subpatch with a parameter-on-parent? In that case, the parent patch will indeed lose the value of that (and only that) parameter, and apply the default. If you find it loses all settings, please provide steps to reproduce this, and I'll sort it out.
Have read the last couple of posts after taking a late night break on the Axo. AEST time here.1.29 AM as I write. The community library is exactly what it is, a library. A collection of items that some people may or may not find interesting. And it is up to those who are looking for something to search for what meets there interests. And the important thing when searching a library is to be quiet so you don't distract others. The most challenging thing in libraries which is likely to eventuate here, is large content, and how you want to manage that content to make it easier for everyone to use, a sort of software infrastructure of sorts. Arduino achieves this with users being able to create there own libraries for tasks, that can be connected to their IDE, and others with libraries you can download and add yourself to the IDE. And this works very well especially considering their IDE is used for many different types of boards which some libraries are updated, modified, or newly created to meet these needs. I guess what I am trying to say, its late and I'm very tired, I maybe waffling on a bit,, but the Axo is open source, has a community library people can choose to participate in, or just browse, lets talk and discuss, but for me, I need to keep the volume down.
Yes, it is a complicated problem, that is why I think it is good to atleast have a debate about it. I think it is nice to know which problems users encounter when using the community library.
But for a new user who dont know these things, which we cannot expect everyone to do, it can be a problem that one object has suddenly changed.
Again, I totally understand the issues that was presented by TB and Gavin and others.
Maybe it is just me who have been personally hit by this a couple of times and that is why it concerns me.
Anyway, as I said, I think I'll have to be more careful and copy all objects to my own library. This is the best solution for now. Or embed them.
I think there should be proper communication between developers and users, that's the very basis. Since the library is not name-sensitive, i believe that labeling newer objects with "beta" could be a decent solution. The object should go through an arbitrary amount of beta time. If a developer is designing a family of related objects, he could upload them as "beta", and keep them like that until he's sure (to a certain degree) that he won't change them. This way, if an (educated) user wants to use a beta object, he can take precautions and embed the object.
Far from perfect, but i think it's much better than versioning.
I disagree, how would one then define it is no longer a beta based object ? Who becomes responsible for changes / updates ? What if a user gets the beta object and modifies it their own way ? does this then create a beta version of a beta version ?
I think there are a lot of benefits in the current setup, we have the factory objects, I see these as the fundamental basics of all objects, it would be nice to see some growth in this area.
The community objects are "use at your own risk", with the exception of the fact that the community resources are available to assist you. The developer of a community object should have the right to post an object in the Library, and then no longer want any more association with it. We see this all the time with Arduino, so why should this be any different. The only difference is once again we have the community forum to seek assistance within, and those who wish to assist can.
The more I think about my comments above, in fact maybe the Factory Library and the Community library should be more separate within the Axo gui then it is current. The Factory library should be more of a part of the gui, whereas the community library is more community contributions. That's not say that it isn't already, what I mean is, like Arduino has standard libraries that come with the IDE, whereas other libraries are added by personal choice. This way the future of the community library and its management will naturally take its own path separate from the factory library which could be fixed to the gui and its updates or something similar. And its related to the topic because it is about separating the interest of the community library from the factory one, and ensures they do not have influence over one another. Just a thought anyway,
I dont see any reaon to seperate com.lib and fact.lib more than it is.
Well off course the user who uploaded the objetc is responsible for maintaining it. IF it needs maintaining....... And that is the whole point of having this discussion. Think before you upload, dont upload anything you plan to change 10 times within the next 2 days! But if you do... Then write BETA in the objects name. This would warn people if BETA or not.
I dont find this a problem at all. In any patch i use several custom objects. Could you describe what you mean?
No one is saying anything about changing the com.lib.. We talk about how to administrate the com.libs content, not how to change it!
I dont agree with "use at own risk" at all. Not good practice to change objects for the comlib. all the time. And I really dont think the developer, @johannes, would be interested in having a not trustable com.lib. . Why would anyomne want to do that, change objects all the time in com.lib? Makes no sense to me and it will make the com.lib totally not trustable. The whole BETA term COULD potentially warn people that an object is up for change in the near future, and then it would be the users decision to choose if they like to use it or not, embedd it for secuirty or what ever.
To seperate fact.lib from com.lib..... I dont see any reason to do that. I think the smart hting about Axolotis com.lib. is that it is actually available INSIDE the program. Not like reaktor user library etc., where you have to go to external webpage and download install, etc.... Annoying. Axoloti si very smart in this matter, cause it has got the com.lib available form the GUI. Man if I had to go to an external source everytime I use an objects form the community library... I'd go mad.. Not a good solution.....
Anyway, IF the com.lib. was removed, which I dont see any reason to do at all, ..... How would you managed it? I am curious about that!
Thanks for the response Jaffa, but the point I am trying to make is somewhat different in context. The concept here is to let all users find their own path through the relevant content. Everyone has different interests, everyone has different skills, and more importantly we all have different goals. In fact this is where the "use at your own risk" comes into play. The risk you take is using an object that not isn't doing what you think it will, but also the creator of the object should they choose may no longer have any interest in discussing the operation of the object. The freedom of choice within the content is what truly is "open source". But my description is not as negative as it sound, like many open source communities, if the creator isn't helpful, there is a good chance you can find someone who will be. Creativity in this sense is like a flood, you start of going down the river, its narrow, it starts to speed up, it gets deeper and wider, and continues to get deeper, then eventually it bursts the bank and could go anywhere. This is what you want. Sure you can keep trying to channel the flood down the river, but you need to stop it getting deeper, and this has its own problems, because it inhibits creativity. Think of it more like a "Watch and learn from everyone / no-one" project. The following quote from TB earlier in this post is brilliant..
The only difference between an Artist and a Scientist, is, a scientist can't afford to be absurd, whereas an Artist can't afford not to be. With the Axoloti you have a chance to capture both.
That is why we are talking about guidelines... NOT rules....
If majority follows those guidelines, it should be ok. But seriously, would you think that an object library that changed the objects functions all the time would be useful? I dont think it is.
BUt I know changes WILL be made and therefor I think it is good practice to avoid users getting their patches destroyed time after time... Again, I had 2 objects being changed in a couple of days, which broke MANY patches. This could easily become a lot more and if they whole library is like that.... Come on, that would be very bad... Do you really not see that?
there is a need for stability, and yet there is also a requirement that there is a 'low barrier' of entry.
as i said previously, Im happy to have guidelines, in fact more broadly, I see this could be part of help/guidelines on "how to create objects" that work well in axoloti. it could contain things like naming conventions and also tips and tricks that aid interoperability - this would all be cool, Im all for new contributors having a resource to learn 'good practices'
on the flip side, the community library is open to all contributions, regardless if the contributor has read/followed the guidelines or not. so contributors don't need to be concerned if they are 'doing it right', they can just share whatever they want.
for the future release, we want to help both users of the library and the contributors.
improve 'stability' by allowing users to have more options IF an object is going to break there patches
given contributors more control over their library of objects, and ability to maintain different versions (eg. stable vs beta, if they wish)
our goal is to continue to make it easy, so anyone with or without a technical background can contribute, be it a huge library of objects, or just a few patches.
when I proposed and implemented the community library, I clearly stated, this was not a final solution, more a way to get the ball rolling and to 'see how it goes'. personally I think it seems to have been successful , thanks to the contributors! . of course 'living' with it and hearing feedback, has highlighted both its strengths and weakness. I hope on the next major dev cycle, to make some significant changes to address these.
note: I consider the factory library a different 'animal', its centrally maintained, and stability is paramount.
beta - id avoid adding to the name. but i see no harm having a separate folder in the contributors library e.g. tb/experimental/tempomapper.axo , then the contributor can move it to the 'correct' folder when its considered 'stable'
I hope in the next major release cycle to work on a new object/patch browser, and I want to include tags with this, so then a tag would be an option. (though there will then be other choices )
True, but the problem we're addressing here is "update at your own risk". No amount of rhetoric is going to change the fact that updating and finding half of the connections lost is a bad thing, and any effort from object developers to mitigate this is a step closer to a better community library. Also, it seems you have no idea about how the library works contributor-side.
I agree there are some creative users that would be shackled by these guidelines, and they might not want to follow them, no problem. But having some contributors comply with this would increase the quality of the library (and i generally prefer quality over quantity)
Id be happy to sum up what we have discussed in this thread and write down the "conclusions" we have made. It will take a little while, cause I got full time job and 2 kids and music to be made too.
When I have something, I'll post it and users and comment on it before it is put in wiki.
I do agree that the com.lib. should be for everyone, but I dont see any reason why not administrate it just a tiny bit.
I think com.lib have become very important to Axoloti. There is sooo much stuff in there now, that we could not do without.
Also fine with me. As long as it is some how clear that it is an object in development that is being used, that can change.
Exactly!
Me too but having general guidelines are a good thing.
I maybe waffling on a bit,, but the Axo is open source, has a community library people can choose to participate in, or just browse, lets talk and discuss, but for me, I need to keep the volume down. 
