hello Frank,
thanks for your modification. it's better now. there is a problem anyway : it's hard to move the 1st masse : sometime we move the link. the problem is that there is now way to say that some point should not be editable with the mouse, and somes other should.
thanks
Cyrille
Frank Barknecht wrote:
Hallo, Nicolas Montgermont hat gesagt: // Nicolas Montgermont wrote:
You point out a useless CPU charge of my patch! Thanks to you I can add mass and link to my simple model, but the computation remains difficult for a structure which is designed to replace a fader. The only way seems to have a template containing all the masses positions and to have one global set for all of them, but the number of masses won't be easily editable...
That allowed me to discover something about displaying datastructure. The X-offset present at the starting point of the link depends of the number of link present here, I explain : The first link added to a mass got good position (links 0, 1, 2 of the test patch) , the second one and every others (3,4) linked to him got a 1/2 pixels addition on their x-display, and so on. So link added last got a x move of ~7 pixels! I've disabled your x addition of 5 pix to see that better.
Interesting problem, indeed. I will need to take a deeper look at this. Anyway I now tried another thing which both made another (although only a small) speedup as well as fix the display: I change the links from being an array inside the model to being single data structure object. This makes the [traverse X, next( messages hit the wrong object for the masses, so I changed how they gat their pointers, too. My changes are in [pd structure] and in mass-setter/link-setter. You will probably spot them easily, I added comments.
Ciao