I forgot to add, I am interested in feedback on this particular feature. Right now its in there to try out. I'm not yet convinced it should be permanent, but it does offer some advantages, especially on mobile phones and smaller computers.
.hc
On Apr 11, 2011, at 12:59 PM, João Pais wrote:
of course, I saw that being discussed some days ago. ok.
On Mon, 11 Apr 2011 17:32:19 +0200, Hans-Christoph Steiner <hans@at.or.at
wrote:
Most vanilla objects are split out into their own 'vanilla' lib right now. So if you don't add "vanilla/list" and "vanilla" to the libraries loaded by default, they won't be loaded. You can do [import vanilla/list vanilla] to quickly try a patch without changing your prefs.
.hc
On Apr 11, 2011, at 9:03 AM, João Pais wrote:
Hi,
I thought about downloading a build of pd-ext 0.43 that works, to try it out. But the version I tried yesterday is apparently not ok, for example even cnv objects don't exist. Does anyone noticed a previous windows build that is more stable? (even if it doesn't have all the extra objects)
João
--Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 Studio +49 30 69509190 jmmmpais@googlemail.com | skype: jmmmpjmmmp
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.
-- Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 Studio +49 30 69509190 jmmmpais@googlemail.com | skype: jmmmpjmmmp
----------------------------------------------------------------------------
Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra
you mean this lib structure? as long as they're configured properly, I myself don't see any difference - talking from the "dumb user" point of view.
it might be better to lock them, or hide them from the editor - this would prevent someone who is trying out stuff to delete them. but maybe it's too much trouble for something that will likely hardly happen...
I forgot to add, I am interested in feedback on this particular feature. Right now its in there to try out. I'm not yet convinced it should be permanent, but it does offer some advantages, especially on mobile phones and smaller computers.
Part of the idea is that people can make CPU-optimized versions of 'vanilla' and load them as they need them. So they shouldn't be locked in to using 'vanilla', or I would have just left those objects built-in.
.hc
On Apr 11, 2011, at 7:31 PM, João Pais wrote:
you mean this lib structure? as long as they're configured properly, I myself don't see any difference - talking from the "dumb user" point of view.
it might be better to lock them, or hide them from the editor - this would prevent someone who is trying out stuff to delete them. but maybe it's too much trouble for something that will likely hardly happen...
I forgot to add, I am interested in feedback on this particular feature. Right now its in there to try out. I'm not yet convinced it should be permanent, but it does offer some advantages, especially on mobile phones and smaller computers.
----------------------------------------------------------------------------
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/12/2011 01:46 AM, Hans-Christoph Steiner wrote:
Part of the idea is that people can make CPU-optimized versions of 'vanilla' and load them as they need them. So they shouldn't be locked in to using 'vanilla', or I would have just left those objects built-in.
i think a better approach (than to have no [f] object) would be, to automatically load the std library until explicitely requested not to do so. e.g. add a "-nostdlib" flag to disable loading of the "vanilla" library. this seems to be perfectly in line with the current set of flags, and minimizes problems with 99% of the users
fgamsdr IOhannes
On Apr 12, 2011, at 4:21 PM, IOhannes m zmölnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/12/2011 01:46 AM, Hans-Christoph Steiner wrote:
Part of the idea is that people can make CPU-optimized versions of 'vanilla' and load them as they need them. So they shouldn't be locked in to using 'vanilla', or I would have just left those objects built-in.
i think a better approach (than to have no [f] object) would be, to automatically load the std library until explicitely requested not to do so. e.g. add a "-nostdlib" flag to disable loading of the "vanilla" library. this seems to be perfectly in line with the current set of flags, and minimizes problems with 99% of the users
The vanilla libdir will include [f], [t], [b], etc. you don't need a - nostdlib option to do that. I so no reason to add a different library loading mechanism when we have one that works.
.hc
----------------------------------------------------------------------------
kill your television
Quoting "Hans-Christoph Steiner" hans@at.or.at:
The vanilla libdir will include [f], [t], [b], etc. you don't need a -nostdlib option to do that. I so no reason to add a different library loading mechanism when we have one that works.
excuse my ignorance, but i'm only proposing that the "vanilla" library should be loaded by default, unless the user decides that they don't want that.
if you indeed read my mail like this, then i would like you to explain to me again, why you needed additional search paths like ~/pd-externals/ to be compiled into pd, when we have a perfectly working method to add "~/pd-externals" (well, given that the tilde expansion works) to the search paths: "-path ~/pd-externals".
removing the core objects from Pd seems a more aggressive assault to people's workflows than having them manually add some "standard" search paths.
either you do make exceptions or you don't.
fgmaftr IOhannes
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
On Apr 13, 2011, at 10:54 AM, zmoelnig@iem.at wrote:
Quoting "Hans-Christoph Steiner" hans@at.or.at:
The vanilla libdir will include [f], [t], [b], etc. you don't need a -nostdlib option to do that. I so no reason to add a different library loading mechanism when we have one that works.
excuse my ignorance, but i'm only proposing that the "vanilla" library should be loaded by default, unless the user decides that they don't want that.
if you indeed read my mail like this, then i would like you to explain to me again, why you needed additional search paths like ~/ pd-externals/ to be compiled into pd, when we have a perfectly working method to add "~/pd-externals" (well, given that the tilde expansion works) to the search paths: "-path ~/pd-externals".
That is not quite a good analogy. The existing method was there: a folder that was searched by default called path/to/pd/extra. You did not need to specify -path path/to/pd/extra. ~/pd-externals is just another folder in that same list of folders to search.
removing the core objects from Pd seems a more aggressive assault to people's workflows than having them manually add some "standard" search paths.
either you do make exceptions or you don't.
I want nothing aggressive or assaulting. The idea is to solve problems like:
- wanting use a SIMD-optimized version of the core objects for things that need it - ability to use the new GUI/editor features while maintaining compatibility with older versions of Pd (i.e. steps towards the separation of the editor and the runtime).
.hc
----------------------------------------------------------------------------
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/13/2011 05:11 PM, Hans-Christoph Steiner wrote:
That is not quite a good analogy. The existing method was there: a folder that was searched by default called path/to/pd/extra. You did not need to specify -path path/to/pd/extra. ~/pd-externals is just another folder in that same list of folders to search.
i think it is a good analogy. objects are loaded by default ("vanilla" set of objects). afair, you never needed to import "vanilla" to create [f].
however, what my analogy is really about is, that there is a startup flag "-nostdpath" which will _prevent_ path/to/pd/extra to be searched for objects. hence my suggestion to load "vanilla" by default, and add a flag "-nostdlib" to prevent loading of this if you need to.
removing the core objects from Pd seems a more aggressive assault to people's workflows than having them manually add some "standard" search paths.
either you do make exceptions or you don't.
I want nothing aggressive or assaulting.
i appreciate that and i admit that using both "aggressive" and "assault" was a bit of an overshoot.
The idea is to solve problems like:
- wanting use a SIMD-optimized version of the core objects for things
that need it
a) i fully understand and support this. b) i don't understand how my suggestion breaks with your idea. you can always do a "-nostdlib -lib chocolate" to replace vanilla with stracciatella.
c) i don't understand how this is not possible with current Pd. as has been shown numerous times that you can simply override existing objects. cf. zexy's [pack] and gf's [print].
basically it seems that you are proposing something complicated to achieve something that is just there.
- ability to use the new GUI/editor features while maintaining
compatibility with older versions of Pd (i.e. steps towards the separation of the editor and the runtime).
i'm all in favour of separating editor and runtime, and providing cool features. i fail to see how this is accomplished by forcing people to load core objects (and in fact leaving them with a bare, non "working" (for about all of the people) version of Pd)
fgmasdr IOhannes
On Wed, 2011-04-13 at 19:09 +0200, IOhannes m zmölnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/13/2011 05:11 PM, Hans-Christoph Steiner wrote:
That is not quite a good analogy. The existing method was there: a folder that was searched by default called path/to/pd/extra. You did not need to specify -path path/to/pd/extra. ~/pd-externals is just another folder in that same list of folders to search.
i think it is a good analogy. objects are loaded by default ("vanilla" set of objects). afair, you never needed to import "vanilla" to create [f].
however, what my analogy is really about is, that there is a startup flag "-nostdpath" which will _prevent_ path/to/pd/extra to be searched for objects. hence my suggestion to load "vanilla" by default, and add a flag "-nostdlib" to prevent loading of this if you need to.
removing the core objects from Pd seems a more aggressive assault to people's workflows than having them manually add some "standard" search paths.
either you do make exceptions or you don't.
I want nothing aggressive or assaulting.
i appreciate that and i admit that using both "aggressive" and "assault" was a bit of an overshoot.
The idea is to solve problems like:
- wanting use a SIMD-optimized version of the core objects for things
that need it
a) i fully understand and support this. b) i don't understand how my suggestion breaks with your idea. you can always do a "-nostdlib -lib chocolate" to replace vanilla with stracciatella.
c) i don't understand how this is not possible with current Pd. as has been shown numerous times that you can simply override existing objects. cf. zexy's [pack] and gf's [print].
basically it seems that you are proposing something complicated to achieve something that is just there.
- ability to use the new GUI/editor features while maintaining
compatibility with older versions of Pd (i.e. steps towards the separation of the editor and the runtime).
i'm all in favour of separating editor and runtime, and providing cool features. i fail to see how this is accomplished by forcing people to load core objects (and in fact leaving them with a bare, non "working" (for about all of the people) version of Pd)
First, its not done yet, so yes there are problems. It'll be invisible to all Pd-extended users except those that want to know about it. That's my pledge.
Second, you don't even use Pd-extended, so you are hardly the target audience.
.hc
-
Hans-Christoph Steiner -
IOhannes m zmölnig -
João Pais -
zmoelnig＠iem.at