Open discussion about the best way to update community library objects!

#13

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.

#14

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, :grin:

#15

Maybe remove BETA from the name of the object?

I think this is a good solution.

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!

#16

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.
:grin:
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. :stuck_out_tongue:

#17

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?

#18

I agree with you both :slight_smile:

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 :wink:)

#19

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)

#20

@thetechnobear

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.

+1

#21

You are correct, it does seem that way, but it is not true.
I have sourced many contributor programs for Arduino that were done several years ago and have found that they will no longer support their contribution, but are happy for anyone to use. And it would be wrong of me to expect they continue to support it. Same should apply here. TB's idea of an experimental folder is probably a very fair solution.

To be honest, my biggest concern is having contributor objects with the expectation that it will do a certain thing. If I create an object and complete it, and you try using it and find that it does not do what you want, does that then allow you to say it is not complete or in a worse case scenario say it does not belong in the contributor library ?

Please know, I am not a synth guy, I know absolutely nothing about synthesizers, but am trying to learn through the Axo. I am in my mid 40's, Love punk / alternative music ever since the mid 80's. I play the bass guitar, in fact I own 6. What I play is extremely noisy, overdriven and psychedelic, I have been addicted to effects since I started playing the bass. I taught myself to program visual basic many years ago, and this is why I got into the Axo. I had never worked with a micro processor before until I picked up and Arduino 4 years ago, the maker community has opened my eyes significantly. I put building my CNC machine on hold while I build up my Axo unit. I have relied very heavily on contributors and open source makes this very possible for anyone, I wouldn't have an Axo if it wasn't. One day I hope I have something to offer in return, but the last thing I want, is to be judge for my contribution, and I have seen how this can happen.

This is an open discussion and I am being open. The above is just to show maybe how different my goals are from everyone else or somewhat, so I will always see things in a way that suit my needs. :grin:

#22

?????????????????

You totally missed my point, again.
If you create an object that does something, it's up to you to tell if it's complete or not. Users have absolutely no role in this, but it's your responsibility (at least moral) to provide an object that creates the littlest trouble possible.
If you upload an object that is not complete, and you are aware of it, and you wish to update it in the future, you can simply let users know your intentions. This way users are prepared for an eventual update. Some patches will eventually break, but not all of them.

Also, let me clear some things for you: what i upload in the community library i can edit it. Noone else can, except maybe for Johannes or Mark. Same thing applies for me: i can't edit other users' content, unless i make a copy of it inside my personal folder.
I'm not judging you because you're not a contributor, i'm just pointing out that you have confused ideas about the community library

#23

Not confused, just have enough experience to recognize the impact of expectations .:grin:

#24

Just a little to add.. If you are correct..

and

Here is you fundamental problem, if it isn't, then I am the only one on the forum with this problem and I would then need to think very seriously about my continuation with Axoloti because Open Source is all about contributor content. Otherwise what other options would I have.

Don't fret, I'm not packing up, just explaining the point.. ! :grin:
But I might think twice about a subject heading starting with the words "Open Discussion." :stuck_out_tongue:

#25

@Gavin

Sorry, this is just gibberish. NO ONE have ever said anything like that. You are taking it too far... And creating non existing problems. If you read throigh this whole thread noone has ever said anything about objects has to follow certain standards. Again, we are talking guidelines, not rules. We talked about that it is important that atleast do some thinking BEFORE uploading.... Is the oject still in development, then it is important to tell the user, so the user can make a decision on what to do.

Ehh, wow....

I made the thread, not @Sputnki

So, you are maixing thing up @Gavin !!!

And I will call the thread EXACTLY what I want. Please....... You are welcome to contribute to the debate like everyone else in here. And your contribution will be weigthed in, like everyone else in here. I made the thread to have everyones opinion, and then Ill take out what makes most sense and use that. But you havent really contributed anything to the com.lib. yet, so it is hard to know where you are coming from!

Going to work now...

Have a good day!

#26

I think all participants in this thread have expressed their option, and their viewpoint on others opinions.

Id suggest the thread moves on, perhaps focusing on what the guidelines might be, and most importantly what has broken peoples patches... and if these are expected or if we can make software changes to make patches 'less fragile'.

I would be interested on hearing other users/contributors opinions on this topic, and also the impact object changes has had on their patching experience. Im interested if others are quietly nodding their heads or don't feel this impacts them much.

#27

@johannes and I have been discussing this, with respect to the next major dev cycle.
we view 'breaking of patches due to library updates' as a technical issue to be resolved.
for the next major release we want to 'fix it', so that regardless of library changes, a user will be able to open a previous patch, and for it to function exactly as before. so users patches will not be broken because a contributor changes the interface or behaviour of an object.

last night, we came up with an approach we think will tackle this.
its too early to give details, as some areas will still need to be thrashed out when we start the dev cycle and during implementation - this will not happen till after 1.0.12 is released.
(before you ask, no we don't have a timeline for either 1.0.12 or next dev cycle :wink: )

Im not suggesting this makes guidelines less useful, it simply means the impacts of contributors not following guidelines, would be significantly reduce.

#28

here is a detailed workaround (including video) for recovering objects if you have broken patches due to interfaces changes.
(the basic approach is to use git to retrieve previous versions, so whilst shown for mac/windows, you can do the same with the command line on linux)

#30

This sounds awesome. I could do with less, but it seems like you put some thoughts into it.

Anyway, yes, let's move on and focus on what we can do to prevent too much trouble for users.

The guidelines: as mentioned, I dont mind summing it up in a piece of text. All ready started. Ill let you know when I have some more....

#31

Sorry guys, was only using a little sarcasm to try and lighten things up a little, definitely no harm was intended.

#32

i dont want rules but recommendations about naming objects

#33

Hihi :slight_smile: Name objects after their function is a good place to start :wink: So it doesnt get too obscure.