normalizeToSum to any number method

Development
1

I know i’m a noob (ish), and annoying probably
But I thought maybe this would be helpful. Instead of normailzeSum just to 1. A method that will normalize to any number.

+ Array {
    normalizeToSum { |targetSum|
        var currentSum = this.sum;
        ^this * (targetSum / currentSum);
    }
}

// Example usage

a = [1, 2, 3, 4];
b = a.normalizeToSum(10);
b.sum.round(0.001); // Should return 10

Goes in Extensions folder.

2

Nice work, and I don’t mean to discourage,
but in this case, I would just use

b = a.normalizeSum * 10

as it’s actually less characters I think…

(I’ve also picked up that it’s generally better if possible / when you intend to share code to make a new subclass rather than adding methods to an existing class… i.e.

MyBetterArray[slot] : Array {
  normalizeToSum { |targetSum| ^this.normalizeSum * targetSum }
  /* add more methods here */
}

and then:

a = MyBetterArray [1, 2, 3];
b = a.normalizeToSum(10);
b

for instance, if I run your code that depends on your special array method, I might forget to remove your array method from my class library and then accidentally use normalizeToSum in some code I then send to someone else, and then it’s a mess. (It’s already a bit of a mess because of quarks library and lack of namespacing…) But this way, the default behavior of an array stays the same whether or not your extension is installed, and it’s much easier to share code.

3

Or we could rename it . NormSt(10)
There ,. shorter. No dangling operator. I don’t know, i how’s it any different than any other method ? Add it to sc and there will be no conflicts. Try running any code with a version of supercollider from 5 years ago. Or code from 10. I definitely agree it is annoying, it just keeps happening…always a deprecated message eventually, I don’t know how these things get added permanently, I’m just offering up an idea.

4

Actually, I have complex projects from 10 years ago that open flawlessly still. Part of why this is possible is the developers have become very resistant to adding lots of new methods to the core library. (Recently there was discussion about adding a new weighted choose method that automatically normalizes weights, but this is a rare occurrence and very carefully discussed. This kind of conservatism can be irritating, but it certainly helps with long term backwards compatibility and stability.

If you run

Array.dumpAllMethods

you will see listed about 1000 instance methods. (around 300 are inherited from Object – which means every single object inherits these same methods.) When people talk about “class library bloat” this is some of what they mean. This is basically an intractable problem: for backward compatibility where you can open old projects without worry, SC can’t ever remove any methods from the class library. So adding a new one is an infinite maintenance burden, etc.

See also this thread about best practices for quarks:

5

I understand now, , thank you. Makes sense

6

I’m unsure if it’s the quantity of methods and inheritances or the architecture itself. While it’s true that there are a lot of things in the std lib, I don’t believe it’s a good thing to keep repeating some sentences like this and also discouraging quarks.

I see that supercollider is what it is, and if there was a mistake, it was never a “punk phase when everything goes,” but it is the limit of this particular OOP architecture. People coming from languages with good tooling (and corporate/professional settings, etc.) and organizations, of course, will think something terrible happened in the development of SC. But no.

Part of that comes from smalltalk itself (the idea of an ocean of objects, where the point is not objects but messaging) and people having fun doing this. When people stop coding and making music for fun, it’s the end)))