Sputnki contributions

#27

Added sequencer/24ppq2click.axo
Which is a cheap metronome.

#28

In the next days i'm gonna be updating the topology of the looper patch, in order to make it more solid (i'm also working on a quantizer object, which needs these edits).
To do this i had to change some objects: in particular the looper/endpos bpm, which will become looper/length bpm and will lose the startpos and endpos outlets (substituted by a length outlet).
The looper/pos object will be changed too: it will no longer have startpos and endpos as inputs, but as outputs, and will take length as input.

This will break patches.
If you have already used such objects and don't want to update patches, you can convert all looper objects to patch/object. (click on the arrow -> embed as patch/object)

I'm sorry for this inconvenience, but i hope to extend the functionalities of the looper
(also this update will benefit the looper/pos2phase and looper/pos2ppq objects)

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

Man I just went through this with another user. I think it is not a good idea to make that drastic changes to objects.

Anyway, it is of course your choice, but I really dont think it is good practice, unless something is totally off in the object, something that might be misleading or not working.

My issue was that inputs had been renamed and also a parameter had been renamed. Which resultet in all input connections was lost and the parameter that had been changed lost its values.

Why not just make a new version with those features?

#30

Not a good practice, i know, but it's an important change that will benefit patches in terms of functionalities(with the new objects you will be able to make odd time loops, for example), stability and, to some extent, cpu load.
Also, these are all objects that are meant to work together, so it won't be hard to patch em up back again, with the aid of the help patch.
Also i published something like 6-7 objects in two days. While i had in mind what the end goal was i still did not know how to implement it correctly, and in the making of the more advanced objects i recognized the need for a better and more solid implementation.

Since i had some problems with my axocomputer, i won't be publishing those changes for a while (more time for users to read this and take precautions).

I'll be here for troubleshooting after the update, so don't worry too much!

#31

Coool. Sounds like you put some thought into it :wink:

Anyway, because I experienced this a few times, I started copying the objects that I use the most to my own library and use them from there. This eliminate the problem.

Anyway, thank you for the warning :wink:

#32

yeah, without going too off topic....

changing interfaces and behaviour is a 'fact of life' with any software development (=custom objects/subpatches).
the developer needs to move forward, and even if they create a new object (v2) so dont break existing ones, they will probably not want to maintain the old one ... so the user in the end, has to move to v2.

Johannes and I have talked about this quite a bit, in the more 'generic' case , as its also a potential issue with factory objects, some of this was discussed here : https://sebiik.github.io/community.axoloti.com.backup/t/object-lifecycle/1629/3
really its more of a 'general problem' we need to solve.... you can't prevent change, but we can manage it better.

personally, Im thinking
a) using the fact that git IS a version control system, i.e. even if a current version of an object is change, git still has the old version.
b) simplifying 'embedding' e.g. having a 'freeze patch' concept, where all objects/subpatches are 'frozen/embedded' into a patch. (it can later be 'unfrozen') ... a bit like how in ableton you can 'collect resources' for a project.

anyway, we still need to work it out... but I think as the user base and community library grows it becomes a more 'pressing' problem.

#33

yes!
So if I change the code inside my/object , will that also break patches? can i edit the overview without breaking patches?

#34

I do agree to a certain extend, progess will happen, But I also believe that the saying "why fix it if it aint broke" is really good one. I dont see any reason to change something that is not broke. If it is working, why do you want to change it? Why not only make a new one?

I do understand changing things from a developers perspective, but not from a user perspective. And I guess there are more users that developers, so please take user perspective into consideration too. I really dunt understand the arguments about maintaining old ones. I dont think this have been an issue in any cases in here yet with maintaining them. What do you mean by that. Updating SHA or similar? Can you give an example?

Like I said, if there is somethin to fix, fix it, if not leave them alone and add new objects instead. I really dont see why you would like to mess with stuff that is functionally working. The only thing that wil happen it that you will create a load of problems for the users...... Which could be solved by just making a new one instead of overwritting the old one. Problem solved! I strongly believe that stuff uploaded to the the com.lib, should be thought throug BEFORE uploading it to com.lib, so you dont make problems for the user later on. Differnet objects can be good for different cases.

But I guess I will just make my own copy of the com.lib on local disc. I do suspect this to become a big problem for users in the near future. 1 object have been changed, which broke A LOT of my patches. I think it is a serious issue. ANd this is basicly telling me: dunt trust the com.lib. Dont use objects form there. Copy them to own disc! I think it would be sad if the com.lib. has that tag on it.

Exactly! Be careful with what you do!

#35

perhaps I explained this badly, developers do not change interfaces without good reasons, as they are well aware of the impact it has on users, so avoid as much as possible - so it not should not be a frequent occurrence.

back to axoloti, we of course manage this in the factory library (and firmware etc), but with a community library its up to individuals, and how they view the sharing of objects etc.

my comments was more, with a large code base its inevitable it will happen occasionally, so we need a way to deal with it, not really more or less than that.

as for why it change is inevitable, how its avoided, cost on maintenance, its a big topic, best discussed over beers :beers:

#36

No, this is all fine
Mainly we are taking about deleting or renaming inlets/outlet ( or entire objects)

Of course there are also 'soft breaks' where you change an objects behavior, so the patch still compiles but doesn't behave/sound the same as before.
This is still from a user perspective 'bad' , and in some ways worst .. as it's not always obvious why their patch is not acting the same as before.

Again, I think this was discussed on the above link.
( I suggest any more discussion on this should move to that topic , it's a bit OT here)

#37

Cool. That is great to hear. But in few days I noticed one object change, which has broke a lot of my patches and another user announced a future chance for an object. This is 2 cases in a couple of days, so I think we need to adress it soon. But yes true, there is a difference between factory library and community library. But still I think it is nice to have not rules, but guidelines of what is good practise.

Can we please do it en Belgium then, Johannes homebase? I love Belgium beers......... :wink:

#38

@jaffasplaffa
You're right when you say that if something ain't broken it should not be changed. Also some time ago i stated that contributions should be regulated some way, in order to avoid object flooding and this kind of issues (i guess this makes me an hypocrite then)

What if we write some contributor guidelines? I mean not only a list of written rules, but some kind of Magna Carta Axolotum to be signed from contributors.

As for the technical aspects of object updating, i think i'll leave that to devs. To me a decent (but not excellent) solution could be some kind of "macro" function that embeds all community objects. No extra bloat on github, just on end user's hard disk :smiley:

#39

Haha, I dont consider you anything like that :wink:

Actually I last night I had similar thoughts about some objects I have made. I made new versions of it, and named them something else, that matches it its function better. And now I wonder if I should remove the old and upload the new ones. But I am not sure what to do right now, cause I dont want to break other peoples patches. So I totally understand the dillemma. Also adding new versions could potentially flood the comlib & Github server with loads of similar objects, with different names. So there are different things to consider.

Anyway, I think we should do some guidelines or atleast just have a discussion about it. I will open a new thread right away for this topic, so we dont flood you contribution page with this.

#40

Synced!

The help patch for the looper object has been slightly modified too, hoping to make it clearer.

If anyone is getting errors, PM me and i'll help.

#41

New objects:

sptnk/sequencer/mandelbrot.axo
Iterates over the mandelbrot function z' = z^n +c
Controls for the complex number coordinates and power (up to 16)

sptnk/osc/lissajous.axo
Generates a lissajous figure (x y coordinates) that can be used in conjunction with sptnk/math/2d mapper.axo
Controls for pitch, x and y offset, radius of the circle, phase and frequency multipliers.
By default the object outputs a circle.
xmul and ymul inlets override the respective parameters

sptnk/math/2d mapper.axo
sptnk/math/2d mapper mod.axo
Takes in input two coordinates and outputs a number, based on a function (from a fixed set, between linear, quadratic, cubic and sinusoidal, with a, b, c parameters).
This may sound boring, but some algorithms can produce a pretty raw sound.
Available with interpolated mod input and an option to saturate the input to normal range. Two algorithms allow feedback.

sptnk/math/cartesian2polar k.axo
sptnk/math/cartesian2polar s.axo

Theorically, these object should convert a set of cartesian coordinates to polar.
In practice, the arctan implementation is quite cheap, and distorts the phase a little bit (will be upgraded hopefully)

#42

New object:

sptnk/table/read lissajous.axo
Short explanation: takes the content of a table and draws it around a circle.
Long explanation: a phasor is used both to scan a table and to generate two quadrature sines. The value of the table at the position corresponding to the angle is multiplied by these quadrature sines and added to an offset. The resulting coordinates are then offset by a final amount and then outputted.

Unfortunately i don't have the proper equipment to demonstrate this extensively (not even a sound card :frowning: )
But i can assure it works, i did some tests with the axoloti ghetto recorder and a freeware osc found online.

This is some output with a square/pw table

#43

New objects (anyone likes geometry here?)

sptnk/math/polar2cartesian.axo
sptnk/math/polar2cartesian s.axo
Converts a set of polar coordinates (angle, radius) to cartesian. (2D) (k -rate, s-rate)

sptnk/math/cylindrical2cartesian.axo
sptnk/math/cylindrical2cartesian s.axo
Converts a set of cylindrical coordinates (angle, radius, height) to cartesian. (3D) (k-rate, s-rate)

sptnk/math/spherical2cartesian.axo
sptnk/math/spherical2cartesian s.axo
Converts a set of spherical coordinates (radius,inclination,azimuth) to cartesian. (3D) (k-rate, s-rate)

#44

Should be good for driving an oscilloscope for cool visuals!

a|x

#45

That's exactly what i want to do (even if i don't have an oscilloscope :grin: )
I'm working on some object to project a set of 3d coordinates to 2d

#46

In a previous life, I used to make realtime 3D tools/toys for VJs, so I'd love to see what you come up with.

I have some other ideas about porting ideas from graphics to audio that might be cool.

a|x