Re: [PD] install pd-ext from .deb?
Hallo! >>> your package-manager should handle the dependencies/conflicts correctly, >>> that is: ask you if you want to uninstall the "puredata" package when >>> you try to install the "pd-extended" package. >> as H-C said, it doesn't seem to happen. I only get the error message, and >> no other options available. > > then it might be a bug in the package-manager, but not in the package. The standard package manager (apt-get) on debian and ubuntu does not ask you if you want to uninstall the package - you have to uninstall it manually. Only aptitude is asking these questions ... LG Georg ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] dynamic GOP resize glitch
i could also do what i want by getting the position of my mouse relative to the parent patch. but again, my list archive search was fruitless. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] dynamic GOP resize glitch
my best idea is to use [namecanvas $0-parent] on the parent, ..then get the coordinates of the abstraction, and dynamically send a message to the parent to move the abstraction by 1 pixel, and then move it back again. but i searched the list archives and didn't find a satisfactory way to get the coordinates of an abstraction. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] dynamic GOP resize glitch
i have made an GOP abstraction that dynamically resizes itself when its settings are changed. this all works fine, except for one glitch: the cables leading out of this object are not scaled or moved. this is giving me half-cables, and cables coming out of the middle of an abstraction, etc.. temporary fix is just to turn edit mode on and move the abstraction by 1 pixel, but there must be a better way. any ideas? ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] msd setFixed and setM
Frank Barknecht wrote: > Hallo, > marius schebella hat gesagt: // marius schebella wrote: > >> I just found out that setFixed does not immediately stop a mass, but the >> mass seems to keep the current speed/directions? only if I also send a >> position to the mass it stayes fixed. just want to make sure that this >> is intentional. > > It's intentional and follows Newton's 1st law of motion, though the > name "setFixed" may be misleading: What it does it, it makes a mass > not respond to forces anymore. The effect is that it won't accelerate > or decelerate anymore, which means it keeps its last velocity. thanks, I thought so... marius. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] dropout problems
Maybe is not a PD problem, generally is a Windows problem, try ASIO drivers [1]. It happened to me too. [1] http://www.asio4all.com/ _Ricardo 2008/5/17 Matteo Sisti Sette <[EMAIL PROTECTED]>: > I sent this from the wrong address so I re-send it. In case it reaches the > list twice I apologize. > > > > Hi, > > Curiously enough, I am having CRAZY and inexplicable dropout problems too > (but on windows). > I've described them in a previous thread, and I have no idea whether there > may be any relation between my dropout problems and yours. > > However, there are some similarities: > > 1) I also use two instances of PD: one generating audio (with dsp turned > on), and the other one for only GUI, with dsp turned off. In my case both > are PD-Vanilla. > 2) They communicate with each other with netsend/netreceive > 3) Cpu usage is very low (much lower than yours); even with near to 0% cpu > usage (on both pd instances) I get dropouts > 4) The quantity of messages being sent through netsend/netreceive cannot > justify dropouts: in your case it cannot because the rate of messages is > fixed and you get dropouts only in some cases; in my case, it cannot > justify > because even when NO data is being transmitted in either direction, I get > dropouts > 5) This happens on one machine and doesn't happen on another machine, both > windows xp with the same version of pd (vanilla 0.41-3) and with the same > patches. Both machines are very similar (two laptops from the same vendor > and almost same model) and the non-dropout one does NOT have faster CPU > (though not slower either) - the only difference I can tell is the > non-dropout one has more RAM: 2GB vs one > > In my case, both the audio-generating patch and the GUI-only patch are very > "big", i.e. use much memory (lots of objects containing losts of instances > of lots of abstractions, etc) BUT they are doing _really_ almost nothing > when I still get dropouts. All idle audio abstractions/subpatches are > always > switch~ed off. > > The audio patch has a lot of tables, into which I load a lot of audio data > _at the beginning_ so that uses a lot of memory too - however, even if I > DON'T load audio data (so I do have a lot of tables but they are all very > small and use much less memory) I equally experience dropouts - on one > machine. > > > My only suspects/guesses > A) some memory issue (though using around 100-200 MB memory on a 1GB > machine > shouldn't justify persistent memory trashing generating many dropouts per > second forever) > B) some issue with "big quantity of things", that is: "things which PD > does" > every once in a while even when the patch is not doing nothing, and which > take O(f(N)) time where N is the number of total objects (or total > whatever) > and f(N) is an increasing function? > C) some bug in netsend/netreceive "silently" communicating with each other > even when the patches are not sending anything?? > D) some kind of unexpected interference between multiple instances of > PD > > Are B-D absolute nonsense? > > Probably my issue and yours are unrelated, but I was very surprised to read > another case of unexplicable dropouts and to note the coincidences > (especially 2 instances of PD running and communicating). > > > Andy Farnell mentioned [line] and I assume he meant what he said, i.e. > [line] and not [line~]. > I may have more than a few [line] objects around but they are absolutely > "idle" (as far as I'm responsible) while I get dropouts (i.e. not receiving > input nor producing output). > Same goes for [line~]s that are even switched~ off. > > I test it by listening to an [osc~ 500] when EVERYTHING else is doing > absolutely nothing in both patches and I get dropouts. > > Often (not always), dropouts begin when one may reasonably expect to get a > short burts of dropouts: for example minimizing and maximizing a patch > window full of GUI (note however that I do this on the pd instance that is > NOT generating audio... however this may "steal" cpu to the other instance > for a while) - but then they never ever end!!! > > > Well any clues about Roman's problem may be of interest to me too!!! > > Thanks > m. > > > ___ > PD-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] dropout problems
I sent this from the wrong address so I re-send it. In case it reaches the list twice I apologize. Hi, Curiously enough, I am having CRAZY and inexplicable dropout problems too (but on windows). I've described them in a previous thread, and I have no idea whether there may be any relation between my dropout problems and yours. However, there are some similarities: 1) I also use two instances of PD: one generating audio (with dsp turned on), and the other one for only GUI, with dsp turned off. In my case both are PD-Vanilla. 2) They communicate with each other with netsend/netreceive 3) Cpu usage is very low (much lower than yours); even with near to 0% cpu usage (on both pd instances) I get dropouts 4) The quantity of messages being sent through netsend/netreceive cannot justify dropouts: in your case it cannot because the rate of messages is fixed and you get dropouts only in some cases; in my case, it cannot justify because even when NO data is being transmitted in either direction, I get dropouts 5) This happens on one machine and doesn't happen on another machine, both windows xp with the same version of pd (vanilla 0.41-3) and with the same patches. Both machines are very similar (two laptops from the same vendor and almost same model) and the non-dropout one does NOT have faster CPU (though not slower either) - the only difference I can tell is the non-dropout one has more RAM: 2GB vs one In my case, both the audio-generating patch and the GUI-only patch are very "big", i.e. use much memory (lots of objects containing losts of instances of lots of abstractions, etc) BUT they are doing _really_ almost nothing when I still get dropouts. All idle audio abstractions/subpatches are always switch~ed off. The audio patch has a lot of tables, into which I load a lot of audio data _at the beginning_ so that uses a lot of memory too - however, even if I DON'T load audio data (so I do have a lot of tables but they are all very small and use much less memory) I equally experience dropouts - on one machine. My only suspects/guesses A) some memory issue (though using around 100-200 MB memory on a 1GB machine shouldn't justify persistent memory trashing generating many dropouts per second forever) B) some issue with "big quantity of things", that is: "things which PD does" every once in a while even when the patch is not doing nothing, and which take O(f(N)) time where N is the number of total objects (or total whatever) and f(N) is an increasing function? C) some bug in netsend/netreceive "silently" communicating with each other even when the patches are not sending anything?? D) some kind of unexpected interference between multiple instances of PD Are B-D absolute nonsense? Probably my issue and yours are unrelated, but I was very surprised to read another case of unexplicable dropouts and to note the coincidences (especially 2 instances of PD running and communicating). Andy Farnell mentioned [line] and I assume he meant what he said, i.e. [line] and not [line~]. I may have more than a few [line] objects around but they are absolutely "idle" (as far as I'm responsible) while I get dropouts (i.e. not receiving input nor producing output). Same goes for [line~]s that are even switched~ off. I test it by listening to an [osc~ 500] when EVERYTHING else is doing absolutely nothing in both patches and I get dropouts. Often (not always), dropouts begin when one may reasonably expect to get a short burts of dropouts: for example minimizing and maximizing a patch window full of GUI (note however that I do this on the pd instance that is NOT generating audio... however this may "steal" cpu to the other instance for a while) - but then they never ever end!!! Well any clues about Roman's problem may be of interest to me too!!! Thanks m. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] drop out problem
On Sat, 17 May 2008 22:26:09 +0200 Roman Haefeli <[EMAIL PROTECTED]> wrote: > On Sat, 2008-05-17 at 21:01 +0100, Andy Farnell wrote: > > On Sat, 17 May 2008 21:19:50 +0200 > > Roman Haefeli <[EMAIL PROTECTED]> wrote: > > > > > what do you consider many? i counted 8 [line~]s and 4 [vline~]s in the > > > main patch. the main patch is using 10 instances of an abstraction, that > > > has a [line~], so the sum of all is around 22 [line~] objects. > > > > They are all audio rate (constant cost) so I don't see a problem either. > > In the past I've noticed signal rate [line] > > do you actually mean a message base [line] here? Sorry, that's what I meant. > > > can be a problem. > > yo, in my case, though i am not totally sure, it seems, that sending > 'set' messages to [partconv~] too often causes trouble. i haven't > checked the code, but i don't assume, that sending messages to [line~], > [vline~] or [line] causes spikes in the cpu usage. > > btw: is there a way to monitor the cpu usage on a linux box at a very > high rate, so that short spikes get visible? it would might help me > figuring out, if the really 'set' messages to [partconv~] are causing > troubles. Using top with a combination of -b and -d options might help. > > roman > > > > > > ___ > Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: > http://mail.yahoo.de > -- Use the source ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] drop out problem
On Sat, 2008-05-17 at 21:01 +0100, Andy Farnell wrote: > On Sat, 17 May 2008 21:19:50 +0200 > Roman Haefeli <[EMAIL PROTECTED]> wrote: > > > what do you consider many? i counted 8 [line~]s and 4 [vline~]s in the > > main patch. the main patch is using 10 instances of an abstraction, that > > has a [line~], so the sum of all is around 22 [line~] objects. > > They are all audio rate (constant cost) so I don't see a problem either. > In the past I've noticed signal rate [line] do you actually mean a message base [line] here? > can be a problem. yo, in my case, though i am not totally sure, it seems, that sending 'set' messages to [partconv~] too often causes trouble. i haven't checked the code, but i don't assume, that sending messages to [line~], [vline~] or [line] causes spikes in the cpu usage. btw: is there a way to monitor the cpu usage on a linux box at a very high rate, so that short spikes get visible? it would might help me figuring out, if the really 'set' messages to [partconv~] are causing troubles. roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] most efficient use of [partconv~]
hi again i made a patch, that uses several instances of an abstraction based on the partconv~ external in order to do binaural spatialization of sounds using a set of hrtf tables. the hrtf files are all loaded on loadbang into tables, so that they can be accessed quickly. it is part of the patch, that a 'set ' message to all [partconv~]s is sent quite often, which leads to dropouts on the box, where the installation is meant to run (for some reason not on my personal laptop). i also noticed a difference in performance between an old version of partconv~ (0.1) and the current svn version, whereas the latter is more likely to cause dropout at high 'set' message rates. there are some things, that i don't know, which might affect performance. for instance, what is the recommended blocksize of the subpatch, that contains an object [partconv~]? is the optimal blocksize dependent on the size of the impulse response? is using [partconv~] generally not the best option to implement hrtf? if so, what are better ways? thanks in advance for any help. roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] drop out problem
On Sat, 17 May 2008 21:19:50 +0200 Roman Haefeli <[EMAIL PROTECTED]> wrote: > what do you consider many? i counted 8 [line~]s and 4 [vline~]s in the > main patch. the main patch is using 10 instances of an abstraction, that > has a [line~], so the sum of all is around 22 [line~] objects. They are all audio rate (constant cost) so I don't see a problem either. In the past I've noticed signal rate [line] can be a problem. Glad to hear you've made some progress though. a. -- Use the source ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] drop out problem (improved)
hi again i found out, that i was using two different version of [partconv~] on both boxes: a fresh svn checkout on the dropout box and an old partconv 0.1 on my laptop. i replaced the new by the old version on the dropout box and the situation has much improved, though there are still some dropouts from time to time (while there aren't any at all on my laptop). i could reduce the occurence of drop outs again a bit by lowering the rate from 60Hz to 30Hz (which unfortunately makes some sounds sound a bit 'steppier'). roman On Sat, 2008-05-17 at 21:19 +0200, Roman Haefeli wrote: > what do you consider many? i counted 8 [line~]s and 4 [vline~]s in the > main patch. the main patch is using 10 instances of an abstraction, that > has a [line~], so the sum of all is around 22 [line~] objects. > > i could narrow it a little bit down. i replaced the tracker patch by a > dummy data sending patch and indeed: > > if i send the same message to the audio patch with a constant rate > (16.66ms, respectively 60Hz), there are no dropouts. now, if i alternate > between two different messages at the same rate, the audio patch just > keeps stuttering, while the cpu load increases from 55% to ~70%. > > i also tried a much lower rate: 100ms (10Hz) and 200ms (5Hz) and even > with 5 messages per second, there are dropouts strange > > the same test on the other (slower) box doesn't cause any drop-outs. > > i am a bit stumped. > > roman > > > > > On Sat, 2008-05-17 at 19:17 +0100, Andy Farnell wrote: > > Roman, are you using many [line] objects to interpolate the > > incoming tracker data? > > > > On Sat, 17 May 2008 20:08:26 +0200 > > Roman Haefeli <[EMAIL PROTECTED]> wrote: > > > > > hi all > > > > > > i am setting up a box for an installation. it runs two instances of pd: > > > > > > audio: > > > pd -rt -jack (with only very few externals loaded) > > > > > > tracking: > > > pd -nrt -noaudio (with quite a lot of externals loaded, such as Gem, > > > comport, wiimote and others). > > > > > > both instances talk with each other over two [netsend]/[netreceive] > > > connections (one for each way). the main part of the tcp connection > > > bandwith is tracking data sent from the tracking patch to the audio > > > patch at fixed rate, where each message is 12 floats long. > > > > > > all that runs fine and smooth on my own mobile box: > > > pentium M 1.7GHz > > > 1.5GB RAM > > > ubuntu dapper > > > pd 0.40.3 over jack (48KHz, 1024 frames/period, 2 periods/buffer ) > > > cpu usage is around 80% > > > > > > the same two patches on the installation box cause lots of drop-outs: > > > AMD Athlon XP 2.8GHz > > > 512MB RAM > > > ubuntu gutsy with rt-kernel and everything setup for low-latency > > > pd 0.40.3 (with same jackd settings) > > > cpu usage around 60% > > > > > > funny enough, that the much faster machine with the more appropriate > > > setup (rt-kernel) is having the drop-outs. > > > usually i would suspect [netsend] or [netreceive] to be the cause of the > > > problem. but in this case the data rate sent over the tcp socket is > > > constant, whereas the dropouts only happen, if the tracking data changes > > > values, but not, if the stream from the tracking patch keeps sending the > > > same values. the major part of the audio patch is just some synth stuff, > > > that is constantly running, so there aren't big jumps in cpu usage > > > expected. from what i can tell, the only thing, that happens in the > > > audio patch, when the received stream changes its values, is, that > > > around 10 [partconv~] objects switch tables from a preloaded set of > > > around 1400 tables, where each table is 512 samples long. i don't have > > > an explanation, why this could affect audio (and why it doesn't on my > > > slower mobile box), but this is what i observed. i am happy with any > > > possible explanation of that behaviour and even more with an idea how to > > > solve it. i really would like to avoid not to have to use my personal > > > laptop for the installation. > > > > > > roman > > > > > > > > > > > > > > > > > > > > > ___ > > > Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de > > > > > > > > > ___ > > > PD-list@iem.at mailing list > > > UNSUBSCRIBE and account-management -> > > > http://lists.puredata.info/listinfo/pd-list > > > > > > > > ___ > Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de > > > ___ > PD-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Re: [PD] drop out problem
what do you consider many? i counted 8 [line~]s and 4 [vline~]s in the main patch. the main patch is using 10 instances of an abstraction, that has a [line~], so the sum of all is around 22 [line~] objects. i could narrow it a little bit down. i replaced the tracker patch by a dummy data sending patch and indeed: if i send the same message to the audio patch with a constant rate (16.66ms, respectively 60Hz), there are no dropouts. now, if i alternate between two different messages at the same rate, the audio patch just keeps stuttering, while the cpu load increases from 55% to ~70%. i also tried a much lower rate: 100ms (10Hz) and 200ms (5Hz) and even with 5 messages per second, there are dropouts strange the same test on the other (slower) box doesn't cause any drop-outs. i am a bit stumped. roman On Sat, 2008-05-17 at 19:17 +0100, Andy Farnell wrote: > Roman, are you using many [line] objects to interpolate the > incoming tracker data? > > On Sat, 17 May 2008 20:08:26 +0200 > Roman Haefeli <[EMAIL PROTECTED]> wrote: > > > hi all > > > > i am setting up a box for an installation. it runs two instances of pd: > > > > audio: > > pd -rt -jack (with only very few externals loaded) > > > > tracking: > > pd -nrt -noaudio (with quite a lot of externals loaded, such as Gem, > > comport, wiimote and others). > > > > both instances talk with each other over two [netsend]/[netreceive] > > connections (one for each way). the main part of the tcp connection > > bandwith is tracking data sent from the tracking patch to the audio > > patch at fixed rate, where each message is 12 floats long. > > > > all that runs fine and smooth on my own mobile box: > > pentium M 1.7GHz > > 1.5GB RAM > > ubuntu dapper > > pd 0.40.3 over jack (48KHz, 1024 frames/period, 2 periods/buffer ) > > cpu usage is around 80% > > > > the same two patches on the installation box cause lots of drop-outs: > > AMD Athlon XP 2.8GHz > > 512MB RAM > > ubuntu gutsy with rt-kernel and everything setup for low-latency > > pd 0.40.3 (with same jackd settings) > > cpu usage around 60% > > > > funny enough, that the much faster machine with the more appropriate > > setup (rt-kernel) is having the drop-outs. > > usually i would suspect [netsend] or [netreceive] to be the cause of the > > problem. but in this case the data rate sent over the tcp socket is > > constant, whereas the dropouts only happen, if the tracking data changes > > values, but not, if the stream from the tracking patch keeps sending the > > same values. the major part of the audio patch is just some synth stuff, > > that is constantly running, so there aren't big jumps in cpu usage > > expected. from what i can tell, the only thing, that happens in the > > audio patch, when the received stream changes its values, is, that > > around 10 [partconv~] objects switch tables from a preloaded set of > > around 1400 tables, where each table is 512 samples long. i don't have > > an explanation, why this could affect audio (and why it doesn't on my > > slower mobile box), but this is what i observed. i am happy with any > > possible explanation of that behaviour and even more with an idea how to > > solve it. i really would like to avoid not to have to use my personal > > laptop for the installation. > > > > roman > > > > > > > > > > > > > > ___ > > Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de > > > > > > ___ > > PD-list@iem.at mailing list > > UNSUBSCRIBE and account-management -> > > http://lists.puredata.info/listinfo/pd-list > > ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] install pd-ext from .deb?
João Pais wrote: >>> - Is it possible to install pd-ext where the program already is, >>> usr/local/bin/pd? >> .deb packages SHOULD NOT install to /usr/local (afair; i cannot give you >> any RFC/guideline/bestpractice that confirms this but you should be able >> to find something in the wide,wide,web) > > hmm, that's where synaptic installed pd-ext in the first place. does it > mean that it should be somewhere else? I'll look for some documentation on > that. iirc this was the (imho: buggy) behaviour of older Pd-extended debs. afaik, this has been fixed and pd-extended now installs into /usr. >> the idea is, that you can use one as a drop-in replacement for the >> other: if you have either pd-vanilla (pacakge "puredata") or pd-extended >> installed, you can just run /usr/bin/pd to launch a Pd. > > ah. in that case it would make sense for both to uncompact in the same > folder. but anyway I'm not sure that's the best way. they are 2 different > programs - for example, for a while I had to keep using pd-van, because of > features of data structures that were implemented only from 0.40.x well, i have no solution for you here. if you want to use pd-vanilla then you should install puredata; if you want to use pd-extended, you should use the according package. if the 2 have different versions, you have to decide yourself which one you prefer. mixing the 2 installations can be _a very bad idea_: externals compiled against Pd-extended (that is Pd 0.39) might not work properly with Pd-vanilla (0.41). however, it would be possible to regard both puredata and Pd-extended as totally different applications (with puredata installing to /usr/lib/pd/ and starting with /usr/bin/pd; and Pd-extended installing to /usr/lib/pd-extended/ and starting with /usr/bin/pd-extended, eventually installing a dpkg-alternative to /usr/bin/pd) however it is done: don't mix puredata and Pd-extended >> your package-manager should handle the dependencies/conflicts correctly, >> that is: ask you if you want to uninstall the "puredata" package when >> you try to install the "pd-extended" package. > > as H-C said, it doesn't seem to happen. I only get the error message, and > no other options available. then it might be a bug in the package-manager, but not in the package. fgmasdr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] install pd-ext from .deb?
>> - which is the best way to install the new pd version? or is there a >> way to add a repository where the newest version is available, so >> that synaptic updates it automatically? > > i don't think so. > it might be a good idea. or even a link to the latest builds, if possible. (maybe in another category) >> - Is it possible to install pd-ext where the program already is, >> usr/local/bin/pd? > > .deb packages SHOULD NOT install to /usr/local (afair; i cannot give you > any RFC/guideline/bestpractice that confirms this but you should be able > to find something in the wide,wide,web) hmm, that's where synaptic installed pd-ext in the first place. does it mean that it should be somewhere else? I'll look for some documentation on that. >> - if pd-van (puredata) and pd-ext are different programs, why is the >> new .deb file colliding with 'puredata', that is, pd-van? > > because they are not totally different programs. > the idea is, that you can use one as a drop-in replacement for the > other: if you have either pd-vanilla (pacakge "puredata") or pd-extended > installed, you can just run /usr/bin/pd to launch a Pd. ah. in that case it would make sense for both to uncompact in the same folder. but anyway I'm not sure that's the best way. they are 2 different programs - for example, for a while I had to keep using pd-van, because of features of data structures that were implemented only from 0.40.x > your package-manager should handle the dependencies/conflicts correctly, > that is: ask you if you want to uninstall the "puredata" package when > you try to install the "pd-extended" package. as H-C said, it doesn't seem to happen. I only get the error message, and no other options available. now I don't have time, but then I'll probably uninstall both synaptic-pds, and try the new night build. Joao ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] drop out problem
Roman, are you using many [line] objects to interpolate the incoming tracker data? On Sat, 17 May 2008 20:08:26 +0200 Roman Haefeli <[EMAIL PROTECTED]> wrote: > hi all > > i am setting up a box for an installation. it runs two instances of pd: > > audio: > pd -rt -jack (with only very few externals loaded) > > tracking: > pd -nrt -noaudio (with quite a lot of externals loaded, such as Gem, > comport, wiimote and others). > > both instances talk with each other over two [netsend]/[netreceive] > connections (one for each way). the main part of the tcp connection > bandwith is tracking data sent from the tracking patch to the audio > patch at fixed rate, where each message is 12 floats long. > > all that runs fine and smooth on my own mobile box: > pentium M 1.7GHz > 1.5GB RAM > ubuntu dapper > pd 0.40.3 over jack (48KHz, 1024 frames/period, 2 periods/buffer ) > cpu usage is around 80% > > the same two patches on the installation box cause lots of drop-outs: > AMD Athlon XP 2.8GHz > 512MB RAM > ubuntu gutsy with rt-kernel and everything setup for low-latency > pd 0.40.3 (with same jackd settings) > cpu usage around 60% > > funny enough, that the much faster machine with the more appropriate > setup (rt-kernel) is having the drop-outs. > usually i would suspect [netsend] or [netreceive] to be the cause of the > problem. but in this case the data rate sent over the tcp socket is > constant, whereas the dropouts only happen, if the tracking data changes > values, but not, if the stream from the tracking patch keeps sending the > same values. the major part of the audio patch is just some synth stuff, > that is constantly running, so there aren't big jumps in cpu usage > expected. from what i can tell, the only thing, that happens in the > audio patch, when the received stream changes its values, is, that > around 10 [partconv~] objects switch tables from a preloaded set of > around 1400 tables, where each table is 512 samples long. i don't have > an explanation, why this could affect audio (and why it doesn't on my > slower mobile box), but this is what i observed. i am happy with any > possible explanation of that behaviour and even more with an idea how to > solve it. i really would like to avoid not to have to use my personal > laptop for the installation. > > roman > > > > > > > ___ > Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de > > > ___ > PD-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list -- Use the source ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] drop out problem
hi all i am setting up a box for an installation. it runs two instances of pd: audio: pd -rt -jack (with only very few externals loaded) tracking: pd -nrt -noaudio (with quite a lot of externals loaded, such as Gem, comport, wiimote and others). both instances talk with each other over two [netsend]/[netreceive] connections (one for each way). the main part of the tcp connection bandwith is tracking data sent from the tracking patch to the audio patch at fixed rate, where each message is 12 floats long. all that runs fine and smooth on my own mobile box: pentium M 1.7GHz 1.5GB RAM ubuntu dapper pd 0.40.3 over jack (48KHz, 1024 frames/period, 2 periods/buffer ) cpu usage is around 80% the same two patches on the installation box cause lots of drop-outs: AMD Athlon XP 2.8GHz 512MB RAM ubuntu gutsy with rt-kernel and everything setup for low-latency pd 0.40.3 (with same jackd settings) cpu usage around 60% funny enough, that the much faster machine with the more appropriate setup (rt-kernel) is having the drop-outs. usually i would suspect [netsend] or [netreceive] to be the cause of the problem. but in this case the data rate sent over the tcp socket is constant, whereas the dropouts only happen, if the tracking data changes values, but not, if the stream from the tracking patch keeps sending the same values. the major part of the audio patch is just some synth stuff, that is constantly running, so there aren't big jumps in cpu usage expected. from what i can tell, the only thing, that happens in the audio patch, when the received stream changes its values, is, that around 10 [partconv~] objects switch tables from a preloaded set of around 1400 tables, where each table is 512 samples long. i don't have an explanation, why this could affect audio (and why it doesn't on my slower mobile box), but this is what i observed. i am happy with any possible explanation of that behaviour and even more with an idea how to solve it. i really would like to avoid not to have to use my personal laptop for the installation. roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] help files was: Re: call for testing on the nightly builds!
On Sat, 2008-05-17 at 19:50 +0200, IOhannes m zmoelnig wrote: > Hans-Christoph Steiner wrote: > > > >> i'm not a developer but i would vote for declare > >> i.e. [declare -stdlib mrpeach] to packOSC-help.pd > >> then it would work with pd vanilla too. > > > > The declare/namespace/import stuff is still very undefined, so I > > think some experiementation would be good. I think you should go > > ahead and try it using what you propose. That will be a good test > > case. Then we'll figure out what works best. > > putting the helppatches besides the objects should fix most of the > problems, no? > no need for [declare] orgies and such yo.. it would seem strange having to put [declare]s into help-patches in order to load the the objects, that they are explaining, IMO. roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] help files was: Re: call for testing on the nightly builds!
Hans-Christoph Steiner wrote: > >> i'm not a developer but i would vote for declare >> i.e. [declare -stdlib mrpeach] to packOSC-help.pd >> then it would work with pd vanilla too. > > The declare/namespace/import stuff is still very undefined, so I > think some experiementation would be good. I think you should go > ahead and try it using what you propose. That will be a good test > case. Then we'll figure out what works best. putting the helppatches besides the objects should fix most of the problems, no? no need for [declare] orgies and such fgmasdr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] help files was: Re: call for testing on the nightly builds!
On May 17, 2008, at 5:50 PM, Enrique Erne wrote: > Hans-Christoph Steiner wrote: >> There is much that can and should be done. Here's some ideas >> ranked into of difficulty: >> - file a bug report when a help patch is not working >> - write and improve help patches, and submit them to the patch >> tracker > > is there a convention about how to make it work? i.e. should one > use declare, import or namespace prefix? > > i guess all help-files that are not loaded on default would need a > declare/import/or-namespace in order to work... > > i want to contribute and help to make "all"/more helpfiles work. i > know there is pddp but afaik it does not solve the declare/import/ > or-namespace problem. > > could all developers express their opinion and agree on how to make > all helpfiles work? :) Starting with the PDDP template is a good place to start: http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/doc/pddp/ templates/ > i'm not a developer but i would vote for declare > i.e. [declare -stdlib mrpeach] to packOSC-help.pd > then it would work with pd vanilla too. The declare/namespace/import stuff is still very undefined, so I think some experiementation would be good. I think you should go ahead and try it using what you propose. That will be a good test case. Then we'll figure out what works best. Personally, I would use namespace prefixes: [mrpeach/packOSC]. This will make more sense when there are libraries organized around concepts rather than authors. So something like [osc/packOSC] >> - add a search pane to the help panel > > is this done in tcl/tk? is there any documentation about that on > puredata.info? It is done however you want to, more or less, but I think a pure Tcl solution would be possible, and perhaps easiest. .hc > > > > > >> - help design and code a library format that bundles >> objectclasses, helpfiles, manuals, examples, etc then write code >> to index it all, and create a GUI to navigate that content >> At this point, I think it is mostly a waste of time to do constant >> little workarounds like moving around objects. We should be >> putting our scarce resources towards real improvements, not >> temporary fixes, IMHO. >> .hc >> News is what people want to keep hidden and everything else is publicity. - Bill Moyers ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] sub-ms metro
ok, nevermind
I see it now
from x_time.c:
108 static void metro_ft1(t_metro *x, t_floatarg g)
109 {
110 if (g < 1) g = 1;
111 x->x_deltime = g;
112 }
On Sat, May 17, 2008 at 11:41 AM, Charles Henry <[EMAIL PROTECTED]> wrote:
> Hi, Thomas,
>
> I'm looking at the code right now, and I can't see what you're
> referring to. Is it the x_clock which is limited?
>
> Chuck
>
> On Sat, May 17, 2008 at 10:49 AM, Thomas Grill <[EMAIL PROTECTED]> wrote:
>> Hi all,
>> i'm a bit surprised that i haven't found anything in the archives, so what
>> is the reason that the period of metro can't be lower than 1 ms? (it's
>> limited in the source code).
>> If it's a security thing, so that it prevents cpu overload it should at
>> least be much lower (or even better, just > 0).
>> gr~~~
>>
>>
>> ___
>> PD-list@iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>>
>
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] sub-ms metro
Thomas Grill wrote: Hi all, i'm a bit surprised that i haven't found anything in the archives, so what is the reason that the period of metro can't be lower than 1 ms? (it's limited in the source code). If it's a security thing, so that it prevents cpu overload it should at least be much lower (or even better, just > 0). i totally agree. in the meantime you can use [delay] to build your own metro. frank has posted a patch once. here is another one. fmgasdr IOhannes #N canvas 0 0 450 547 10; #X obj 98 135 t b; #X obj 146 135 t b; #X obj 196 137 != 0; #X msg 98 159 1; #X msg 146 158 0; #X obj 98 186 t f; #X obj 130 408 delay \$1; #X obj 98 387 t b b; #X obj 98 207 select 1 0; #X obj 98 227 t a b; #X obj 156 264 t f f; #X obj 98 361 spigot; #X obj 156 285 > 0; #X obj 156 242 f \$1; #X obj 156 306 t f f; #X obj 188 328 select 0; #X obj 188 348 t b b; #X obj 220 421 print dmetro; #X msg 150 388 stop; #X obj 316 87 inlet rate; #X obj 98 87 inlet control; #X obj 98 437 outlet bang; #X obj 98 112 route bang stop float; #X msg 220 400 refusing rate <= 0: stopping; #X connect 0 0 3 0; #X connect 1 0 4 0; #X connect 2 0 5 0; #X connect 3 0 5 0; #X connect 4 0 5 0; #X connect 5 0 8 0; #X connect 6 0 7 0; #X connect 7 0 21 0; #X connect 7 1 6 0; #X connect 8 0 9 0; #X connect 8 1 18 0; #X connect 9 0 11 0; #X connect 9 1 13 0; #X connect 10 0 12 0; #X connect 10 1 6 1; #X connect 11 0 7 0; #X connect 12 0 14 0; #X connect 13 0 10 0; #X connect 14 0 11 1; #X connect 14 1 15 0; #X connect 15 0 16 0; #X connect 16 0 18 0; #X connect 16 1 23 0; #X connect 18 0 6 0; #X connect 19 0 13 0; #X connect 20 0 22 0; #X connect 22 0 0 0; #X connect 22 1 1 0; #X connect 22 2 2 0; #X connect 23 0 17 0; ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] sub-ms metro
Hi, Thomas, I'm looking at the code right now, and I can't see what you're referring to. Is it the x_clock which is limited? Chuck On Sat, May 17, 2008 at 10:49 AM, Thomas Grill <[EMAIL PROTECTED]> wrote: > Hi all, > i'm a bit surprised that i haven't found anything in the archives, so what > is the reason that the period of metro can't be lower than 1 ms? (it's > limited in the source code). > If it's a security thing, so that it prevents cpu overload it should at > least be much lower (or even better, just > 0). > gr~~~ > > > ___ > PD-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] sub-ms metro
On Sat, 2008-05-17 at 17:49 +0200, Thomas Grill wrote: > Hi all, > i'm a bit surprised that i haven't found anything in the archives, so > what is the reason that the period of metro can't be lower than 1 ms? > (it's limited in the source code). > If it's a security thing, so that it prevents cpu overload it should > at least be much lower (or even better, just > 0). > gr~~~ i am pretty sure, it has been discussed already. though, i am not sure, if ever anyone came up with a good reason for that behavour. to me as well, it seems to be a pretty arbitrary choice. ([until] shouldn't exist, if cpu usage, respectively turning pd unusable, is considered an issue). after all, you could make your own [micrometro] abstraction based on [del], which hasn't such a built-in limit. roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] sub-ms metro
Hi all, i'm a bit surprised that i haven't found anything in the archives, so what is the reason that the period of metro can't be lower than 1 ms? (it's limited in the source code). If it's a security thing, so that it prevents cpu overload it should at least be much lower (or even better, just > 0). gr~~~ smime.p7s Description: S/MIME cryptographic signature ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] help files was: Re: call for testing on the nightly builds!
Hans-Christoph Steiner wrote: > > There is much that can and should be done. Here's some ideas ranked > into of difficulty: > > - file a bug report when a help patch is not working > - write and improve help patches, and submit them to the patch tracker is there a convention about how to make it work? i.e. should one use declare, import or namespace prefix? i guess all help-files that are not loaded on default would need a declare/import/or-namespace in order to work... i want to contribute and help to make "all"/more helpfiles work. i know there is pddp but afaik it does not solve the declare/import/or-namespace problem. could all developers express their opinion and agree on how to make all helpfiles work? :) i'm not a developer but i would vote for declare i.e. [declare -stdlib mrpeach] to packOSC-help.pd then it would work with pd vanilla too. > - add a search pane to the help panel is this done in tcl/tk? is there any documentation about that on puredata.info? > - help design and code a library format that bundles objectclasses, > helpfiles, manuals, examples, etc then write code to index it all, and > create a GUI to navigate that content > > At this point, I think it is mostly a waste of time to do constant > little workarounds like moving around objects. We should be putting our > scarce resources towards real improvements, not temporary fixes, IMHO. > > .hc > ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] msd setFixed and setM
Hallo, marius schebella hat gesagt: // marius schebella wrote: > I just found out that setFixed does not immediately stop a mass, but the > mass seems to keep the current speed/directions? only if I also send a > position to the mass it stayes fixed. just want to make sure that this > is intentional. It's intentional and follows Newton's 1st law of motion, though the name "setFixed" may be misleading: What it does it, it makes a mass not respond to forces anymore. The effect is that it won't accelerate or decelerate anymore, which means it keeps its last velocity. Ciao -- Frank Barknecht _ __footils.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] call for testing on the nightly builds!
There is much that can and should be done. Here's some ideas ranked into of difficulty: - file a bug report when a help patch is not working - write and improve help patches, and submit them to the patch tracker - add a search pane to the help panel - help design and code a library format that bundles objectclasses, helpfiles, manuals, examples, etc then write code to index it all, and create a GUI to navigate that content At this point, I think it is mostly a waste of time to do constant little workarounds like moving around objects. We should be putting our scarce resources towards real improvements, not temporary fixes, IMHO. .hc On May 17, 2008, at 12:54 PM, Rich E wrote: Working here too. Thanks, again it looks great! I wanted to mention that one of the most intimidating things for me when I was first learning about all the externals in pd is that nothing was working by default and I didn't know how to get it working. Pd-extended has come a long way since then, and now I know how to look for missing paths, where to find sources and compile, etc., but I am sure there are many others that give up on pd-extended when things seem 'broken'. I guess what I am suggesting is that something, anything, be one so that the help files can find the externals and the externals can find the help files, by default. If there are issues about organization that are later to be sought out, maybe externals like [pvoc~] should be moved into flatspace until a better solution is committed? rich On Thu, May 15, 2008 at 6:58 AM, Hans-Christoph Steiner <[EMAIL PROTECTED]> wrote: On May 15, 2008, at 5:37 AM, Rich E wrote: The May 9th build doesn't have the same problem. I've also tried the newest nightly build on both Gutsy and Hardy, they have the same "stacksmashing" error. Today's build gets rid of the stacksmashing error (for me at least). Please test! :D http://autobuild.puredata.info/auto-build/2008-05-15/ So now that I've ben searching around in the new Pd-extended, here are some things I noticed: - The new hotkeys (clear console, open help browser) don't work. Fixed. - dragging the pd console window (making it longer) makes the panel longer too, even if it is already big enough (which it is by default Yeah, that could be a lot nicer... .hc - bsaylor's [pvoc~] and [partconv~] externals cannot be found because the path isn't added by libdir (the rest of the externals in the folder appear to be in extra/flatspace, so they can be found. adding /usr/local/lib/pd/extra/bsaylor to the paths list fixes this. That is as far as I've looked.. time to start messing around more. It looks great, by the way! Also, I would like to learn how to commit the changes that I know how to do so Hans doesn't have to bother, but I am having problems with svn right now. I posted another message about this. regards, rich On Wed, May 14, 2008 at 12:52 AM, IOhannes m zmoelnig <[EMAIL PROTECTED]> wrote: Hans-Christoph Steiner wrote: > > You can now file bug reports from the Help menu in Pd-extended. > Please file a bug report for this. i cannot: "/usr/bin/gnome-open 'http://sourceforge.net/tracker/?func=add&group_id=55736&atid=478070' Error showing url: There was an error launching the default action command associated with this location." i guess i should file a bug-report :-) fgmasdr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list -- -- All information should be free. - the hacker ethic "Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you." - Richard M. Stallman ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] call for testing on the nightly builds!
Working here too. Thanks, again it looks great! I wanted to mention that one of the most intimidating things for me when I was first learning about all the externals in pd is that nothing was working by default and I didn't know how to get it working. Pd-extended has come a long way since then, and now I know how to look for missing paths, where to find sources and compile, etc., but I am sure there are many others that give up on pd-extended when things seem 'broken'. I guess what I am suggesting is that something, anything, be one so that the help files can find the externals and the externals can find the help files, by default. If there are issues about organization that are later to be sought out, maybe externals like [pvoc~] should be moved into flatspace until a better solution is committed? rich On Thu, May 15, 2008 at 6:58 AM, Hans-Christoph Steiner <[EMAIL PROTECTED]> wrote: > > On May 15, 2008, at 5:37 AM, Rich E wrote: > > The May 9th build doesn't have the same problem. I've also tried the > newest nightly build on both Gutsy and Hardy, they have the same > "stacksmashing" error. > > > Today's build gets rid of the stacksmashing error (for me at least). > Please test! :D > > http://autobuild.puredata.info/auto-build/2008-05-15/ > > So now that I've ben searching around in the new Pd-extended, here are some > things I noticed: > > - The new hotkeys (clear console, open help browser) don't work. > > > Fixed. > > > - dragging the pd console window (making it longer) makes the panel longer > too, even if it is already big enough (which it is by default > > > Yeah, that could be a lot nicer... > > .hc > > - bsaylor's [pvoc~] and [partconv~] externals cannot be found because the > path isn't added by libdir (the rest of the externals in the folder appear > to be in extra/flatspace, so they can be found. adding > /usr/local/lib/pd/extra/bsaylor to the paths list fixes this. > > That is as far as I've looked.. time to start messing around more. It > looks great, by the way! > > Also, I would like to learn how to commit the changes that I know how to do > so Hans doesn't have to bother, but I am having problems with svn right > now. I posted another message about this. > > regards, > rich > > > On Wed, May 14, 2008 at 12:52 AM, IOhannes m zmoelnig <[EMAIL PROTECTED]> > wrote: > >> Hans-Christoph Steiner wrote: >> > >> > You can now file bug reports from the Help menu in Pd-extended. >> > Please file a bug report for this. >> >> i cannot: >> "/usr/bin/gnome-open >> 'http://sourceforge.net/tracker/?func=add&group_id=55736&atid=478070' >> Error showing url: There was an error launching the default action >> command associated with this location." >> >> >> i guess i should file a bug-report :-) >> >> fgmasdr >> IOhannes >> >> ___ >> PD-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> > > > > > > > > All information should be free. - the hacker ethic > > > > > ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] call for testing on the nightly builds!
Hans-Christoph Steiner wrote: > > On May 13, 2008, at 10:06 AM, Enrique Erne wrote: > >> Hans-Christoph Steiner wrote: >>> Hey all, >>> I've been fixing quite a lot of bugs in preparation of making the Pd- >>> extended 0.40.3 release. It's getting pretty much ready, so please >>> test it heavily so we can find any outstanding bugs! >>> Jack just pointed out that pdp on Mac OS X/PowerPC is having >>> problems loading videos, and is crashing, so I am working on that now. >>> .hc >> >> >> hi Hans >> >> i have been happily working with pd-0.40-extended (20080222) for quite >> a while. there are some issues though. >> >> Pd-0.40.3-extended-20080504-macosx104-i386 on a osx 10.5.2 >> >> - >> >> 1) at the moment if one modifies the preferences of i.e. vanilla pd >> the pd-extended looses all path and startup preferences (this is on >> osx i don't know about win or linux). >> >> i would like to propose that >> ~/Library/Preferences/org.puredata.pd.plist will be completely ignored >> by pd-extended. instead only the org.puredata.pd.plist inside the >> pd-extended app should be used. >> this way one could have different working setups. what do you think? > > I think people want to save preferences for Pd-extended too. The > current situation isn't great, that's true. If people want separate > preferences, that might be a possibility in a future Pd-extended release. ah i forgot that the file inside the app is not save-able > >> >> - >> >> 2) as i reported earlier >> http://lists.puredata.info/pipermail/pd-list/2008-01/058787.html >> some objects can't create. i think that all of them are know problems. >> for me not be able to use <~ and >~ is _most_ annoying >> (hexloader-something?). i know there are workarounds with expr. >> not including iem-t3 lib is a loss but i can live without it. thou it >> makes around 5 nice netpd patches not usable anymore. > > > You can now file bug reports from the Help menu in Pd-extended. Please > file a bug report for this. i wrote a bug report for iem_t3 i'm not sure about the hexloader. i found this: http://sourceforge.net/tracker/index.php?func=detail&aid=1637460&group_id=55736&atid=478070 should i file a new bug report? >> - >> >> 3) help files >> most help files worked (could create) but some: >> >> iemmatrix/matrix-help.pd >> mtx >> ... couldn't create >> >> mrpeach/packOSC-help.pd >> packOSC >> ... couldn't create >> >> sssad/sssad-help.pd >> sssad key >> ... couldn't create >> libdir_loader: added sssad to the canvas-local path >> sssad key >> ... couldn't create >> >> i wondered why some help files worked and some not. i thought it was >> done by org.puredata.pd.plist settings. so i added sssad >> loadlib40 >> sssad >> restarted pd, but the help files still couldn't create. > > please file bug reports for each of these. done > >> >> - >> >> 4) name clash >> [curve] Gem vs. mapping >> probably some more > > Yeah, that's been around a lot time. > >> >> - >> >> what are the goals? which externals are supposed to work on default? >> are that the ones in the plist? maybe we should focus on them (before >> i start to open all help files :) ) > > The goal is to fine bugs and fix them :). Some of the bigger well-known > problems will have to wait until the next release. The externals in the > plist should work without a namespace prefix. All included externals > should work. uhm . now i filed bug reports for helpfiles of externals that are not on the plist. but they work with namespace prefix (except iem_t3) > >> - >> >> thanks for all your work and thanks to all the other devs too! > > > Thanks for your bug reports and your work with Pd! > > .hc > >> >> eni >> > > > > > > > Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's > about as sensible to say we declare war on night attacks and expect > we're going to win that war. We're not going to win the war on > terrorism.- retired U.S. Army general, William Odom > > > ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] install pd-ext from .deb?
On May 17, 2008, at 10:37 AM, IOhannes m zmoelnig wrote: > João Pais wrote: >> Hi, >> >> >> So I wanted to ask: >> >> - which is the best way to install the new pd version? or is there >> a way >> to add a repository where the newest version is available, so that >> synaptic updates it automatically? > > i don't think so. > it might be a good idea. > >> >> - Is it possible to install pd-ext where the program already is, >> usr/local/bin/pd? > > .deb packages SHOULD NOT install to /usr/local (afair; i cannot > give you > any RFC/guideline/bestpractice that confirms this but you should be > able > to find something in the wide,wide,web) > > so "just" installing the package SHOUT install to /usr/lib > you can however manually extract the content of the package using > % dpkg -x Pd-*.deb /extraction/path > > so you could install the package manually to /usr/local > it is not recommended however > > >> >> - if pd-van (puredata) and pd-ext are different programs, why is >> the new >> .deb file colliding with 'puredata', that is, pd-van? > > because they are not totally different programs. > the idea is, that you can use one as a drop-in replacement for the > other: if you have either pd-vanilla (pacakge "puredata") or pd- > extended > installed, you can just run /usr/bin/pd to launch a Pd. > > your package-manager should handle the dependencies/conflicts > correctly, > that is: ask you if you want to uninstall the "puredata" package when > you try to install the "pd-extended" package. I recently added the conflict with 'puredata' and it seems that GDebi, the GUI .deb installer, doesn't really handle it well. It just gives you an error about the conflict, but doesn't seem to allow you to uninstall 'puredata'. Ideally, there would be a smoother way to handle this, but I wonder if it is something that can be done by editing the package description (control/debian) >> - I have already changed some files / made copies of them in the same >> folder. In case I install the new version on the same folder, will >> only >> repeated files be overwritten? (f.e., "default.pdsettings" will be >> for >> sure overwritten, but "default.pdsettings_backup" on the same >> folder won't >> disappear?) > > if it does overwrite a configuration-file without asking you, then > this > is clearly a bug. dpkg should handle all that, it works for all other packages. It'll prompt you if you want to overwrite, and it'll save the overwritten version as .dpkg-old or someting like that. .hc > > > mfga.sd > IOhannes > > ___ > PD-list@iem.at mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/ > listinfo/pd-list "[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] install pd-ext from .deb?
João Pais wrote: > Hi, > > > So I wanted to ask: > > - which is the best way to install the new pd version? or is there a way > to add a repository where the newest version is available, so that > synaptic updates it automatically? i don't think so. it might be a good idea. > > - Is it possible to install pd-ext where the program already is, > usr/local/bin/pd? .deb packages SHOULD NOT install to /usr/local (afair; i cannot give you any RFC/guideline/bestpractice that confirms this but you should be able to find something in the wide,wide,web) so "just" installing the package SHOUT install to /usr/lib you can however manually extract the content of the package using % dpkg -x Pd-*.deb /extraction/path so you could install the package manually to /usr/local it is not recommended however > > - if pd-van (puredata) and pd-ext are different programs, why is the new > .deb file colliding with 'puredata', that is, pd-van? because they are not totally different programs. the idea is, that you can use one as a drop-in replacement for the other: if you have either pd-vanilla (pacakge "puredata") or pd-extended installed, you can just run /usr/bin/pd to launch a Pd. your package-manager should handle the dependencies/conflicts correctly, that is: ask you if you want to uninstall the "puredata" package when you try to install the "pd-extended" package. > > - I have already changed some files / made copies of them in the same > folder. In case I install the new version on the same folder, will only > repeated files be overwritten? (f.e., "default.pdsettings" will be for > sure overwritten, but "default.pdsettings_backup" on the same folder won't > disappear?) if it does overwrite a configuration-file without asking you, then this is clearly a bug. mfga.sd IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
