hello,
thanks to La kitchen and Ircam, Nicolas will work on pmpd for the next 4 mounths. He is an Ircam student doing is train at La kitchen.
He will focuss on the pmpd object, tring to make it more usable, make some exemples, and try to make the integration with data structure.
if time allows it, he will also work on pmpd~.
so, if anybody have idea regarding pmpd, it's time to share it...
i think i'll make an official release of the work done at the beggining of the summer. if someone is interested with the work in progress, please contact Nicolas.
Frank, i hope you've got things to share with Nicolas, he already made good use of you data structure tutorial...
cheers, Cyrille
Hallo, cyrille hat gesagt: // cyrille wrote:
thanks to La kitchen and Ircam, Nicolas will work on pmpd for the next 4 mounths. He is an Ircam student doing is train at La kitchen.
He will focuss on the pmpd object, tring to make it more usable, make some exemples, and try to make the integration with data structure.
if time allows it, he will also work on pmpd~.
Great news. I'm really using pmpd stuff a lot currently, though my stuff is not performance ready at all yet, but I hope to get something done for the Linux Audio Conference in April. Yes, I definitely will come up with some ideas or "feature requests" then.
I also will try to clean up some of my patches, which already incorporate data structures in some applications. For example I have a "physical structure editor" in the works, which so far is still a bit very confusing.
The basic idea there is, to design a physical structure using data structures for masses and links, where thickness of the structures corresponds to weight or damping, and then parse this and create the pmpd-network out of it. I used dynamic messages and dyn~ for the network so far.
It somehow works already, but creating and drawing the connections is still an unsolved problem. Currently I use float ids (drawnumber) at the link's endpoints to specifiy, which mass is to connect to a link, but I want to try some kind of more automatic collision detection next. Then a link, whose end hits a mass in the data structure display, is automatically read as a link connected to that mass.
But I'm babbling, I'll let patches speak later. ;)
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: fqdn _ http://footils.org/cms/show/38
Frank Barknecht wrote:
Hallo, cyrille hat gesagt: // cyrille wrote:
thanks to La kitchen and Ircam, Nicolas will work on pmpd for the next 4 mounths. He is an Ircam student doing is train at La kitchen.
He will focuss on the pmpd object, tring to make it more usable, make some exemples, and try to make the integration with data structure.
if time allows it, he will also work on pmpd~.
Great news. I'm really using pmpd stuff a lot currently, though my stuff is not performance ready at all yet, but I hope to get something done for the Linux Audio Conference in April. Yes, I definitely will come up with some ideas or "feature requests" then.
I also will try to clean up some of my patches, which already incorporate data structures in some applications. For example I have a "physical structure editor" in the works, which so far is still a bit very confusing.
The basic idea there is, to design a physical structure using data structures for masses and links, where thickness of the structures corresponds to weight or damping, and then parse this and create the pmpd-network out of it. I used dynamic messages and dyn~ for the network so far.
have you considered using TkZinc for an editor GUI interface? It's *2D only*, but simple and powerful - i use it with python, pyext and dyn~ and have been very satisfied so far.
vincent
Frank Barknecht wrote:
Hallo, cyrille hat gesagt: // cyrille wrote:
thanks to La kitchen and Ircam, Nicolas will work on pmpd for the next 4 mounths. He is an Ircam student doing is train at La kitchen.
He will focuss on the pmpd object, tring to make it more usable, make some exemples, and try to make the integration with data structure.
if time allows it, he will also work on pmpd~.
Great news. I'm really using pmpd stuff a lot currently, though my stuff is not performance ready at all yet, but I hope to get something done for the Linux Audio Conference in April. Yes, I definitely will come up with some ideas or "feature requests" then.
I also will try to clean up some of my patches, which already incorporate data structures in some applications. For example I have a "physical structure editor" in the works, which so far is still a bit very confusing.
The basic idea there is, to design a physical structure using data structures for masses and links, where thickness of the structures corresponds to weight or damping, and then parse this and create the pmpd-network out of it. I used dynamic messages and dyn~ for the network so far.
have you considered using TkZinc for an editor GUI interface? It's *2D only*, but simple and powerful - i use it with python, pyext and dyn~ and have been very satisfied so far.
vincent
Le 11 Mars 2005 15:59, vincent rioux a écrit :
have you considered using TkZinc for an editor GUI interface? It's *2D only*, but simple and powerful - i use it with python, pyext and dyn~ and have been very satisfied so far.
Interesting, but the site is broken: http://www.tkzinc.org/
-- Marc
Marc Lavallée wrote:
Le 11 Mars 2005 15:59, vincent rioux a écrit :
have you considered using TkZinc for an editor GUI interface? It's *2D only*, but simple and powerful - i use it with python, pyext and dyn~ and have been very satisfied so far.
Interesting, but the site is broken: http://www.tkzinc.org/
quite strange... apparently their wiki is broken this link works though ftp://ftp.ath.cena.fr/pub/Tkzinc/
unfortunately the doc seems to be only available for debian systems they apparently compiled it for windows also now...
let's hope that their site will be up again soon
vincent
TkZinc is back...
have you considered using TkZinc for an editor GUI interface? It's *2D only*, but simple and powerful - i use it with python, pyext and dyn~ and have been very satisfied so far.
Interesting, but the site is broken: http://www.tkzinc.org/
-- Marc
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
Le 20 Mars 2005 08:38, vincent rioux a écrit :
TkZinc is back...
Yes! And I made Debian packages. I tried one demo and read a short tutorial. My impression is that Tkzinc could be quite useful. :-)
have you considered using TkZinc for an editor GUI interface? It's *2D only*, but simple and powerful - i use it with python, pyext and dyn~ and have been very satisfied so far.
Interesting, but the site is broken: http://www.tkzinc.org/
-- Marc
-- Marc
hello Frank,
Frank Barknecht wrote:
Hallo, cyrille hat gesagt: // cyrille wrote:
thanks to La kitchen and Ircam, Nicolas will work on pmpd for the next 4 mounths. He is an Ircam student doing is train at La kitchen.
He will focuss on the pmpd object, tring to make it more usable, make some exemples, and try to make the integration with data structure.
if time allows it, he will also work on pmpd~.
Great news. I'm really using pmpd stuff a lot currently, though my stuff is not performance ready at all yet, but I hope to get something done for the Linux Audio Conference in April. Yes, I definitely will come up with some ideas or "feature requests" then.
thanks
I also will try to clean up some of my patches, which already incorporate data structures in some applications. For example I have a "physical structure editor" in the works, which so far is still a bit very confusing.
wow, the aim of next pmpd object is to make this possible!!! you're going faster than me...
The basic idea there is, to design a physical structure using data structures for masses and links, where thickness of the structures corresponds to weight or damping, and then parse this and create the pmpd-network out of it. I used dynamic messages and dyn~ for the network so far.
ok, i would love to see your patch, and to improve pmpd in that way. i would prefer not to use other dependency than pd / pmpd .
It somehow works already, but creating and drawing the connections is still an unsolved problem. Currently I use float ids (drawnumber) at the link's endpoints to specifiy, which mass is to connect to a link, but I want to try some kind of more automatic collision detection next. Then a link, whose end hits a mass in the data structure display, is automatically read as a link connected to that mass.
But I'm babbling, I'll let patches speak later. ;)
ok, thanks Cyrille
Ciao
Hallo, cyrille hat gesagt: // cyrille wrote:
Frank Barknecht wrote:
I also will try to clean up some of my patches, which already incorporate data structures in some applications. For example I have a "physical structure editor" in the works, which so far is still a bit very confusing.
wow, the aim of next pmpd object is to make this possible!!! you're going faster than me...
Well, I'm still far away from real usability ad the patch is a real mess. ;) A REAL one! If it's cleaned up I'll send it immediatly. But the last days I was a bit distracted by scanned synthesis stuff. I've put the result online now at: http://footils.org/cms/show/41
It's a simple scanned string thing much like your corde.pd, which is an obvious inspiration. I am using dyn~ there to simplify creation of the pmpd-model a lot. The string length is settable now, although I still create a whole new string everytime the length changes.
There are some abstractions inside, which may be useful for other purposes, too, for example a list normalizer for lists with variable length.
I used xgroove~ in the actuallöy scanning engine, which works much more clean than phasor/tabread4, however maybe still not clean enough for dynamically changing tables if the changes are large.
An advantage of [dyn~] also is, that I can manage the connections to a [pack] with it as well, so a lot of manual patching work can be skipped with it. I think, because of something like a "configurable list outlet" for pmpd~ could be useful as well.
Oh, and I now also switched to pd-0.38-test which supports dynamic tables and arrays much better with less dropouts.
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: fqdn _ http://footils.org/cms/show/38
Hello,
I've been experimenting pmpd with datastructure for a week now, and I encounter a few problems that are all present in the attached patch:
- Computation speed! The simple model presented here (5 mass, 8 link)
seems to charge all my CPU at a metro period of 100ms. The string patch designed by Frank Barknecht in the datastructure tutorial was much more faster. Does anybody see any "bad" programming in the patch?
- The datastructure displays strangely on my linux system. Some links
are well connected to the mass, but the others present a kind of offset. Even if the same abstraction is use to display all of them. It seems to be a recurrent problem with the datastructure already discuss in the GoP positions thread. Have you any newer explanations and perhaps solutions ;) ?
- I use the $0 variable to have mutiple instanciation, but I have to use
the external "sprintf" to build the "pd-$0-data" message. Is there a solution using only native pd objects to do that?
Thanks, Nicolas
The patch to open is test.pd
Hallo Nicolas, Nicolas Montgermont hat gesagt: // Nicolas Montgermont wrote:
I've been experimenting pmpd with datastructure for a week now,
Wow! That's quite a patch for one week, wonderful!!
and I encounter a few problems that are all present in the attached patch:
- Computation speed! The simple model presented here (5 mass, 8
link) seems to charge all my CPU at a metro period of 100ms. The string patch designed by Frank Barknecht in the datastructure tutorial was much more faster. Does anybody see any "bad" programming in the patch?
I also get a very high load. I will need a bit time to take a deeper look, but generally the data structures are far from the efficiency that e.g. Gem has. However I don't think your model should be that slow.
- use the $0 variable to have mutiple instanciation, but I have to
use the external "sprintf" to build the "pd-$0-data" message. Is there a solution using only native pd objects to do that?
Yes, and it even works better here (maybe I have another sprintf, I get lots of errors like "sprintf: no method for float").
Anyway the solution is to replace every "sprintf" with "makefilename", you can keep the "pd-%d-data" part, it's the same for makefilename.
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: "scans" _ http://footils.org/cms/show/41
Here are videos (screen captures, not yet the actual installation) and part of the code of my Fwish (Bassin du destion) installation. One version has fish that do not collide, the other does not because I decided it is nicer when the fish overlap.
http://www.danslchamp.org/mrtof/code.htm
tom tom@danslchamp.org
On Tue, 15 Mar 2005 18:30:41 +0100, Frank Barknecht fbar@footils.org wrote:
Hallo Nicolas, Nicolas Montgermont hat gesagt: // Nicolas Montgermont wrote:
I've been experimenting pmpd with datastructure for a week now,
Wow! That's quite a patch for one week, wonderful!!
and I encounter a few problems that are all present in the attached patch:
- Computation speed! The simple model presented here (5 mass, 8
link) seems to charge all my CPU at a metro period of 100ms. The string patch designed by Frank Barknecht in the datastructure tutorial was much more faster. Does anybody see any "bad" programming in the patch?
I also get a very high load. I will need a bit time to take a deeper look, but generally the data structures are far from the efficiency that e.g. Gem has. However I don't think your model should be that slow.
- use the $0 variable to have mutiple instanciation, but I have to
use the external "sprintf" to build the "pd-$0-data" message. Is there a solution using only native pd objects to do that?
Yes, and it even works better here (maybe I have another sprintf, I get lots of errors like "sprintf: no method for float").
Anyway the solution is to replace every "sprintf" with "makefilename", you can keep the "pd-%d-data" part, it's the same for makefilename.
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: "scans" _ http://footils.org/cms/show/41
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
Hallo, Thomas Ouellet Fredericks hat gesagt: // Thomas Ouellet Fredericks wrote:
Here are videos (screen captures, not yet the actual installation) and part of the code of my Fwish (Bassin du destion) installation. One version has fish that do not collide, the other does not because I decided it is nicer when the fish overlap.
So far I could only see the 01-version, which is very cute!
However: You seem to be on an operating system, where upper/lower case doesn't matter: guts/FWISH.pd is referenced as [guts/fwish] in your main patch. But this will not be found on Linux and proper Unixes, which see "X" as something totally different than "x".
Some similar errors show up inside your patch, I'll go hunt them down now.
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: "scans" _ http://footils.org/cms/show/41
hello,
thanks for the video, they are nice.
cyrille
Thomas Ouellet Fredericks wrote:
Here are videos (screen captures, not yet the actual installation) and part of the code of my Fwish (Bassin du destion) installation. One version has fish that do not collide, the other does not because I decided it is nicer when the fish overlap.
http://www.danslchamp.org/mrtof/code.htm
tom tom@danslchamp.org
On Tue, 15 Mar 2005 18:30:41 +0100, Frank Barknecht fbar@footils.org wrote:
Hallo Nicolas, Nicolas Montgermont hat gesagt: // Nicolas Montgermont wrote:
I've been experimenting pmpd with datastructure for a week now,
Wow! That's quite a patch for one week, wonderful!!
and I encounter a few problems that are all present in the attached patch:
- Computation speed! The simple model presented here (5 mass, 8
link) seems to charge all my CPU at a metro period of 100ms. The string patch designed by Frank Barknecht in the datastructure tutorial was much more faster. Does anybody see any "bad" programming in the patch?
I also get a very high load. I will need a bit time to take a deeper look, but generally the data structures are far from the efficiency that e.g. Gem has. However I don't think your model should be that slow.
- use the $0 variable to have mutiple instanciation, but I have to
use the external "sprintf" to build the "pd-$0-data" message. Is there a solution using only native pd objects to do that?
Yes, and it even works better here (maybe I have another sprintf, I get lots of errors like "sprintf: no method for float").
Anyway the solution is to replace every "sprintf" with "makefilename", you can keep the "pd-%d-data" part, it's the same for makefilename.
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: "scans" _ http://footils.org/cms/show/41
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
Hallo Krzysztof, Krzysztof Czaja hat gesagt: // Krzysztof Czaja wrote:
Frank Barknecht wrote: ...
Yes, and it even works better here (maybe I have another sprintf, I get lots of errors like "sprintf: no method for float").
another sprintf -- where from? Are you sure its box is not dashed?
Dashed it wouldn't give this error message. ;)
But I found it now: It's in ext13, at least it was: I might have a very old version here. I now removed all ext13 references in my .pdrc as I think the single externals I might need are in the CVS build anyway without conflicts. Now I get your correct sprintf.
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: "scans" _ http://footils.org/cms/show/41
Hallo, Krzysztof Czaja hat gesagt: // Krzysztof Czaja wrote:
Frank Barknecht wrote: ...
Dashed it wouldn't give this error message. ;)
right, it would give a slightly different one, but equally misleading: "error: inlet: expected '' but got 'float'"
Cool, I had never seen this one actually (I'm still new in 0.38 land) and now the Fish-patch just mentioned is giving me lots of them. ;)
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: "scans" _ http://footils.org/cms/show/41
Ouch, I run in XP. My bad. I will try to clean it up.
Tom
On Tue, 15 Mar 2005 23:29:09 +0100, Frank Barknecht fbar@footils.org wrote:
Hallo, Krzysztof Czaja hat gesagt: // Krzysztof Czaja wrote:
Frank Barknecht wrote: ...
Dashed it wouldn't give this error message. ;)
right, it would give a slightly different one, but equally misleading: "error: inlet: expected '' but got 'float'"
Cool, I had never seen this one actually (I'm still new in 0.38 land) and now the Fish-patch just mentioned is giving me lots of them. ;)
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: "scans" _ http://footils.org/cms/show/41
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
Hi all, now i had a look into pmpd - it's a shame i didn't do earlier, and it's great! It would be good to do some optimization though - only by recompiling the Windows dll with some different flags and changing a bit of suboptimal code the demo-patches were up to 3 times faster than before.
- in many methods in the source gensym calls are used, although they
generate the same symbols at every call - it would be good to generate these symbols in the setup functions and cache them for use by outlet* calls.
- pow(f,2) is used instead of f*f
- reference expressions are often repeated verbatim, although they could
be replaced by a pointer
- the makefile in the src directory has no optimization flags at all for
msvc++. It should have /Ox /G7 or similar, depending on the cpu
best greetings, Thomas
i did some profiling of mass2D and here are some more points:
- since the length of the argument lists are checked at the beginning
of the methods, don't use atom_getfloatarg since it can't be inlined. it's better to use a macro instead
- it's preferable to use inverse masses and distances to avoid divisions
- the random generator sucks a lot of cpu power and can be optimized
(although i don't get the meaning of the range parameter there)
attached is a diff where all the mentioned points are implemented
best greetings, Thomas
Am 17.03.2005 um 00:06 schrieb Thomas Grill:
Hi all, now i had a look into pmpd - it's a shame i didn't do earlier, and it's great! It would be good to do some optimization though - only by recompiling the Windows dll with some different flags and changing a bit of suboptimal code the demo-patches were up to 3 times faster than before.
- in many methods in the source gensym calls are used, although they
generate the same symbols at every call - it would be good to generate these symbols in the setup functions and cache them for use by outlet* calls.
- pow(f,2) is used instead of f*f
- reference expressions are often repeated verbatim, although they
could be replaced by a pointer
- the makefile in the src directory has no optimization flags at all
for msvc++. It should have /Ox /G7 or similar, depending on the cpu
best greetings, Thomas
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
Thomas Grill wrote:
i did some profiling of mass2D and here are some more points:
- since the length of the argument lists are checked at the beginning of
the methods, don't use atom_getfloatarg since it can't be inlined. it's better to use a macro instead
- it's preferable to use inverse masses and distances to avoid divisions
- the random generator sucks a lot of cpu power and can be optimized
(although i don't get the meaning of the range parameter there)
attached is a diff where all the mentioned points are implemented
wow, thanks a lots.
i'll make the modification as soon as possible...
cyrille
best greetings, Thomas
Am 17.03.2005 um 00:06 schrieb Thomas Grill:
Hi all, now i had a look into pmpd - it's a shame i didn't do earlier, and it's great! It would be good to do some optimization though - only by recompiling the Windows dll with some different flags and changing a bit of suboptimal code the demo-patches were up to 3 times faster than before.
- in many methods in the source gensym calls are used, although they
generate the same symbols at every call - it would be good to generate these symbols in the setup functions and cache them for use by outlet* calls.
- pow(f,2) is used instead of f*f
- reference expressions are often repeated verbatim, although they
could be replaced by a pointer
- the makefile in the src directory has no optimization flags at all
for msvc++. It should have /Ox /G7 or similar, depending on the cpu
best greetings, Thomas
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
Hallo, Nicolas Montgermont hat gesagt: // Nicolas Montgermont wrote:
I've been experimenting pmpd with datastructure for a week now, and I encounter a few problems that are all present in the attached patch:
- Computation speed! The simple model presented here (5 mass, 8 link)
seems to charge all my CPU at a metro period of 100ms. The string patch designed by Frank Barknecht in the datastructure tutorial was much more faster. Does anybody see any "bad" programming in the patch?
I tried various things now but the only thing that really helped is, to hide the data structure display, e.g. by switching GOP off for bonhomme.pd. Then CPU usage drops by a huge amount. So it's definitely the graphical updates, that kill performance here.
Anyway what I tried is this: I removed a lot of traversing inside model-setter.pd so it now just stores the correct pointer once on initialization. For that, I added a $0-INIT receive target, which is bang'd in the structure subpatch after the data structres are created.
Performance-wise it didn't help at all, but this approach might be useful for larger structures.
Another test I did was in the opposite direction: I suspected, that maybe access to the array data is slowing things down. So I added another field to the mass-struct for color. I then colorized the movable mass on the house's roof. ;)
You can find the result in the "evenslower" subdirectory. Now this simple little change is totally exhausting my machine. Pd (0.38) isn't able to render the animation at all anymore when I try to move the now red dot.
- The datastructure displays strangely on my linux system. Some links
are well connected to the mass, but the others present a kind of offset. Even if the same abstraction is use to display all of them. It seems to be a recurrent problem with the datastructure already discuss in the GoP positions thread. Have you any newer explanations and perhaps solutions ;) ?
I moved over the masses' display by 5px to the right, which looks better but still is off for some links. Deeper investigation needed...
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: "scans" _ http://footils.org/cms/show/41
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
Another test I did was in the opposite direction: I suspected, that maybe access to the array data is slowing things down. So I added another field to the mass-struct for color. I then colorized the movable mass on the house's roof. ;)
Okay, inspired by this I now tried some more things to optimize setting array data, with good results actually: CPU usage was about halfed (no real benchmark data).
In attached patch I replace the many "set" patches which always just set one single field in an array by abstractions, which use only one [set] inside to set fields in one go. Those are mass-setter.pd and link-setter.pd. They also carry the pmpd-objects inside, which makes the patches clearer.
This turns out to be a big performance boost.
Morale of story (so far): Use the least amount of [set] object, concentrate on bundling [set]. This was news to me, too, thanks for hitting my head at this problem. ;)
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: "scans" _ http://footils.org/cms/show/41
hello frank,
thanks for your optimisation. do you think more improvement can still be made? i'm very disapointed with the curent performances...
cyrille.
Frank Barknecht wrote:
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
Another test I did was in the opposite direction: I suspected, that maybe access to the array data is slowing things down. So I added another field to the mass-struct for color. I then colorized the movable mass on the house's roof. ;)
Okay, inspired by this I now tried some more things to optimize setting array data, with good results actually: CPU usage was about halfed (no real benchmark data).
In attached patch I replace the many "set" patches which always just set one single field in an array by abstractions, which use only one [set] inside to set fields in one go. Those are mass-setter.pd and link-setter.pd. They also carry the pmpd-objects inside, which makes the patches clearer.
This turns out to be a big performance boost.
Morale of story (so far): Use the least amount of [set] object, concentrate on bundling [set]. This was news to me, too, thanks for hitting my head at this problem. ;)
Ciao
Hallo, cyrille hat gesagt: // cyrille wrote:
thanks for your optimisation. do you think more improvement can still be made? i'm very disapointed with the curent performances...
Actually I doubt, that without changes to Pd itself the performance could be optimized much more.
So no "Little Nemo" with data structures yet.
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: "scans" _ http://footils.org/cms/show/41
Hello,
Frank Barknecht a écrit :
Actually I doubt, that without changes to Pd itself the performance could be optimized much more.
So no "Little Nemo" with data structures yet.
Ciao
The only solution seems to use two metros : one for the datastructures update at a period of ~50ms and one for the pmpd objects at a period of ~10 ms. That way, the pmpd structure evolves well and the datastructures don't use too much memory!
Bye,
Nicolas
Hallo, Nicolas Montgermont hat gesagt: // Nicolas Montgermont wrote:
The only solution seems to use two metros : one for the datastructures update at a period of ~50ms and one for the pmpd objects at a period of ~10 ms. That way, the pmpd structure evolves well and the datastructures don't use too much memory!
That would be possible, too, and probably the best solution, as the eye is slow enough to not really care about that difference in framerate (a period of 50 is 20 frames/sec which already is faster than television images.)
However the implementation in the pmpd-editor which is not using arrays (a lot) already is much faster than using array elements. I did a test with a square plane of about 40 masses and performance is quite okay.
I did some more tests using mass3D instead of mass2D, so the editor can be used to specify 3D models using one plane as well. Now I'm wondering how to best make the model data available to other objects, for example scanned synthesis algorithms. But probably something like that is better solved with the future [pmpd] and [pmpd~] objects anyway. ;)
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: "scans" _ http://footils.org/cms/show/41
Hello Frank,
Morale of story (so far): Use the least amount of [set] object, concentrate on bundling [set]. This was news to me, too, thanks for hitting my head at this problem. ;)
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.
I've tried things like setting the plotting width of the line to 0 in place of 2 but the problem is still the same... Perhaps it's a datastructure bug? In this case I can't understand why it's only on the x axe!
Does people on Windows & Mac systems got the same problem?
Thanks Nicolas
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
Frank Barknecht _ ______footils.org__
_ __latest track: "scans" _ http://footils.org/cms/show/41
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
My changes are in [pd structure] and in mass-setter/link-setter. You will probably spot them easily, I added comments.
... which contain at least one misleading spelling error: In link-setter.pd it should read "Every link is now a single struct" instead of "not a single struct".
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: "scans" _ http://footils.org/cms/show/41
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
-
cyrille -
Frank Barknecht -
Krzysztof Czaja -
Marc Lavallée -
Nicolas Montgermont -
Thomas Grill -
Thomas Ouellet Fredericks -
vincent rioux