Re: [PD] Playing and recording simultaneously
On Sun, 4 Jul 2010, Henrique wrote: However, I think the total delay itself is not a problem, because it will appear in my acoustic response estimate. I think I misread the question. Sorry. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] GEM pix_film crashing on OSX 10.5
Mathieu, thanks for all the tips. I will try these out later this week on site. In regards to your question about vline~, I was currently just using the line object to turn up and down the clip volume. All the best, Julio On Mon, Jul 5, 2010 at 9:10 AM, Mathieu Bouchard wrote: > On Mon, 5 Jul 2010, Julio Terra wrote: > > The crash often happens all by itself (e.g. no input is being processed by >> the patch at the time of the crash). >> > > The video you are playing is a kind of input in some manner (though it's > also useful to know that you're not having any other input than that). > > First, check out the Load Meter patch (in the Media menu) and make sure > that the number doesn't increase over time. (though usually, it wouldn't > make the sound disappear suddenly) > > Then, there's a system programme that allows you to check how much RAM the > programmes (.app and others) are using. PureData is represented by two > entries. Make sure that there isn't one that inflates like crazy over time. > Also make sure the CPU doesn't grow over time (Load Meter only reports one > of the CPU values and doesn't tell you about the other entry). > > Then later, check whether it makes a difference whether the result of > [pix_film] is used at all : try disconnecting [pix_texture] but keep > [gemhead] active. > > If you still don't find a difference, try the [pix_film] test with a > reencoding of your video file in a different codec. > > Do you use [vline~] at all, in your audio part ? > > > _ _ __ ___ _ _ _ ... > | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801 > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] software license for pd general patch?
On Mon, 5 Jul 2010, João Pais wrote:
considering that the person wants not to use only max, many of those
reasons above are environmental constraints decided outside, that the
user has no control about
Environmental constraints are real constraints, and are as worthy of
attention, even though they are not technical problems, or are only
indirectly so.
considering we're speaking about the "normal person", that doesn't
either say "I want max" or "I want pd",
I don't think that you're talking about something that is the usual case.
I think that most of people exposed to either max or pd will be so through
some kind of university classroom, and most likely will be forced to use
the software that the teacher decided to use, or that the teacher was
forced to use in the first place, by whatever regulation of the
department.
However, there are several meaningful concepts of "normal" or "most" that
go with the set of people we consider, and to the extent that you can
ignore people that will only have ever used max/pd in the context of
courses, you could be talking about only long-term max/pd users, and
that's something quite entirely different... though they often get started
with max by decree, and then say "I want to not have to relearn this
stuff, so I will stick with Max".
some enhancements were made in (kind of Pd but for visuals)
do you have some kind of audio-centric view of pd here ?... sounds like
some kind of Pd-vanilla idea that Pd is for audio, and by opposition to
that ("unlike pd"), is for visuals.
BTW, my first years of Pd were strictly with visuals, and though I
gradually incorporated tiny bits of audio in my practice, it was really
only this year that I really felt that I was doing a significant amount of
Pd audio, a big audio patch comparable to the big graphics patches I've
been doing for a long time... some things many times bigger than any
previous audio patch I had made.
_ _ __ ___ _ _ _ ...
| Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] Playing and recording simultaneously
:D you just made my day Mathieu. On Tue, Jul 6, 2010 at 2:37 AM, Mathieu Bouchard wrote: > On Mon, 5 Jul 2010, Martin Peach wrote: > > Mathieu Bouchard wrote: >> >>> I recall seeing precisely "44098 Hz" when my soundcard was an ISA >>> Ultrasound (Gravis) some 5-10 years ago, but I don't recall whether it was >>> at Pd's startup, another programme's startup, or both. >>> >> >> I guess if you know the CPU frequency you can count samples to determine >> the sample rate, but that assumes that the CPU clock is what it says it is. >> Relativity and all that... >> > > If you throw a 44100 Hz soundcard in space at 259627884 metres per second, > it will appear to run at 22050 Hz. > > ... > > Anyway, thanks for your answer, seriously. > > > _ _ __ ___ _ _ _ ... > | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801 > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > -- Pedro Lopes contacto: j...@radiozero.pt website: http://web.ist.utl.pt/Pedro.Lopes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Playing and recording simultaneously
On Mon, 5 Jul 2010, Martin Peach wrote: Mathieu Bouchard wrote: I recall seeing precisely "44098 Hz" when my soundcard was an ISA Ultrasound (Gravis) some 5-10 years ago, but I don't recall whether it was at Pd's startup, another programme's startup, or both. I guess if you know the CPU frequency you can count samples to determine the sample rate, but that assumes that the CPU clock is what it says it is. Relativity and all that... If you throw a 44100 Hz soundcard in space at 259627884 metres per second, it will appear to run at 22050 Hz. ... Anyway, thanks for your answer, seriously. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] readanysf~ error
Hi August On Sat, 2010-07-03 at 12:00 +0200, august wrote: > > so, I tracked down this bug. File handles were being inadvertently left > open. > > I made a new version of readanysf~ with reworking of the code based on > adjustments I had been making for other stuff I am working . It should > provide for more stable and modular code. Seeking should also be > non-blocking and smoother now. > > Can I ask linux users to download and test it, please: > > http://aug.ment.org/software/readanysf~0.40.tar.gz make gives me: g++ -c -o objs/ReadMedia.o src/ReadMedia.cpp -I./ -I/usr/include -I/usr/include/gavl -I/usr/include/gmerlin -I/usr/include -Wall src/ReadMedia.cpp: In constructor ‘ReadMedia::ReadMedia()’: src/ReadMedia.cpp:42: error: ‘GAVL_INTERLACE_UNKNOWN’ was not declared in this scope make: *** [objs/ReadMedia.o] Error 1 - By commenting out line 42 of src/ReadMedia.cpp: m_video_format.interlace_mode=GAVL_INTERLACE_UNKNOWN; it compiles fine. Is that GAVL_INTERLACE_UNKOWN thing needed at all for the audio-oriented readanysf~? Should I be worried when commenting it out? Cheers and thanks for the fixes Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] delay time changing
- "Frank Barknecht" a écrit : > Hi, > > On Mon, Jul 05, 2010 at 08:59:37PM +0200, patko wrote: > > using [del] class object for sequencing events, I'm looking for a > similar object that would > > change delay time also for event that has already occured, like a > tempo change. > > > > A patch is attached for demonstrating what I'm looking for > > I'm not sure why the timer "would show 500", shouldn't it be "would > show 750" > i.e. 250 initial delay + 500 new delay? > > The latter can be easily made by connecting the numbers to the first > inlet of > [del] instead of the second. A float into [del] cancels all running > delays and > set the new output-bang to happen delayed by the value of the float. > that's what I was looking for, thank you > Ciao > -- > Frank BarknechtDo You RjDj.me? _ > __footils.org__ > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list -- Patrice Colet ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] delay time changing
Hi, On Mon, Jul 05, 2010 at 08:59:37PM +0200, patko wrote: > using [del] class object for sequencing events, I'm looking for a similar > object that would > change delay time also for event that has already occured, like a tempo > change. > > A patch is attached for demonstrating what I'm looking for I'm not sure why the timer "would show 500", shouldn't it be "would show 750" i.e. 250 initial delay + 500 new delay? The latter can be easily made by connecting the numbers to the first inlet of [del] instead of the second. A float into [del] cancels all running delays and set the new output-bang to happen delayed by the value of the float. Ciao -- Frank BarknechtDo You RjDj.me? _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] delay time changing
Hello, using [del] class object for sequencing events, I'm looking for a similar object that would change delay time also for event that has already occured, like a tempo change. A patch is attached for demonstrating what I'm looking for -- Patrice Colet #N canvas 0 0 660 300 10; #X obj 168 159 delay 1000; #X obj 159 49 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X msg 253 108 1000; #X msg 201 130 500; #X obj 138 180 timer; #X obj 158 70 t b b b; #X floatatom 165 202 5 0 0 0 - - -; #X obj 199 107 del 250; #X text 205 200 <--- would show 500; #X text 197 44 bang; #X text 236 83 after 250ms changes delay time; #X text 240 155 delay ignores time changing \, it would be nice only if new time value is too older than time that has passed \, eg 501 would be ignored.; #X connect 0 0 4 1; #X connect 1 0 5 0; #X connect 2 0 0 1; #X connect 3 0 0 1; #X connect 4 0 6 0; #X connect 5 0 0 0; #X connect 5 1 7 0; #X connect 5 2 2 0; #X connect 5 2 4 0; #X connect 7 0 3 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] readanysf~ error
Great news, August ! I look forward to testing this brand new version. A pity I can't help with mac compiling ... Pierre Le 3 juil. 2010 à 12:00, august a écrit : > > > so, I tracked down this bug. File handles were being inadvertently left > open. > > I made a new version of readanysf~ with reworking of the code based on > adjustments I had been making for other stuff I am working . It should > provide for more stable and modular code. Seeking should also be > non-blocking and smoother now. > > Can I ask linux users to download and test it, please: > > http://aug.ment.org/software/readanysf~0.40.tar.gz > > Hans, > > Could I ask you to make another mac bundle so that it can be tested > for the mac users. The makefile should check if you are on darwin > or not. The setup should be the same, I think and you can just type > "make" > > > > -august. > > >> I also tracked down the "Too many open files" error message. It DOES >> come from readanysf~, .from the gmerlin_avdec library. It is a >> strerror message. >> >> I'm trying to track down now if somewhere file handles are not being >> closed properly. I will probably need a few days to find out. >> >> Do you get any messages in the Terminal, when you start Pd from the Terminal ? (the "open" command of the Terminal doesn't count, as it only asks the Finder to open a file.) >>> >>> Terminal showing first errors : >>> >>> /foo1.wav >>> [demuxer] Info: Detected Microsoft WAV format >>> opened /foo1.wav >>> /foo2.wav >>> [demuxer] Info: Detected Microsoft WAV format >>> opened /foo2.wav >>> /foo1.wav >>> [in_file] Error: Cannot open /foo1.wav: Too many open files >>> Could not open file /foo1.wav >>> /foo2.wav >>> [in_file] Error: Cannot open /foo2.wav: Too many open files >>> Could not open file /foo2.aiff ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] software license for pd general patch?
On Mon, 5 Jul 2010, João Pais wrote: that point was more about the "general interest of the comunity" argument. in any case it's good you don't get that many complaints, which shouldn't mean that there are less users. If you had your own webserver, you would be able to count the number of downloads. exactly, that's a great merit. that's why I always ask someone who hasn't put their code in there if he wants to - it makes it much more centralised, and easier to access. Yeah, though it makes more sense for externals than abstractions, it makes more sense for small libraries than big ones, and it also depends on the library structure and class naming (ask anyone who installed pd-extended and then recompiled iemmatrix from scratch because they can't use the version bundled with pd-extended). this isn't part of my abstractions (at /extra/jmmmp), it's a "full program". it doesn't come with pd-ext, it's on my pd page. I would say that it's as big as all my abstractions together, but never measured it. Ok, now it brings this question to my mind : is there anything you can break away from your full programme such that the full programme becomes smaller and the abstractions library becomes bigger, in a manner that the new abstractions are really things that can be useful for any other purpose than the one of the full programme ? It's a big key for making your full programme worth doing : recycle as many parts as possible, or at least make them recycling-ready. the next time I try to update my object list (you might know the "short version" from the floss manual, the original is an xls file), I would try to include a list of the gridflow objects. http://gridflow.ca/svn/trunk/doc/index.pd is a list of everything, in a manner quite similar to Pd's own class index. This is what appears when you click the GridFlow Index item that GridFlow adds in Pd's Help menu. It currently lists 211 classes, but it's possible that I forgot to list a few. (Considering the features of GridFlow, 211 is a rather small number). I had started talks with a friend that does data visualisation to make a patch to automatise the listing, but he bailed out. so I have to do the work by hand. The GridFlow Index is auto-generated by http://gridflow.ca/svn/trunk/doc/make_index.tcl (which also includes a list of exceptions that have to be made in that patch). You could use that as an idea for building the index in a wiki format or csv format, whichever you need for flossmanual. my jmmmp abstractions are very simple utilities, most of them to spare some repetitive code In the end, every abstraction can be thought of as replacing some repetitive code, but some give that impression more than others. I think it has to do with how unthinkable it is to be doing a certain task without those abstractions (or externals, etc.). if you don't want just to do 10m of 4/4 Well, I don't, but the problem with that, is that I usually want to do 10m of 7/4 instead. ;) But once I know what it's about, then I have more of a chance of finding a use for it and using it as an answer to a question. but that goes back to the initial point: this program was made for persons that play complex music from score, and can need the help of a click track system that lets them reherase/play in concert. that's why I said in the beginning that in this list almost anyone fits into that category what's the definition of "almost anyone" ? Don't underestimate the number of video-centric people. I wonder how many people came to pd because of something else than audio. I am one of them for sure. It took me years before I tried to do any audio at all with pd and... I'm probably not alone. I don't know about your pd club, but my pd club has quite a lot of video in it, and sometimes I can guess that some people hardly do any audio ever ; and I never tried to skew the pd club towards video, and I never heard *anyone* ever suggest that we'd be overrepresentating video. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] compiling pd-extended on arch linux
james, i'm not at all sure what's wrong with your search paths, if i run: pacman -Qo `locate Magick++.h` it reveals: /usr/include/ImageMagick/Magick++.h is owned by imagemagick 6.6.2.0-1 this path should be found by Gem's configure stage, ie: -- checking for PKG_IMAGEMAGICK___CFLAGS... -fopenmp -I/usr/include/ImageMagick checking for PKG_IMAGEMAGICK___LIBS... -lMagick++ -lMagickCore -- i can only suggest to attempt updating your imagemagick package, and check that 'Magick++-config --cppflags' returns an accurate path to the imagemagick headers.. changing the #include to a full path is certainly the wrong way about fixing this.. a correct -I flag at compilation will yield far cleaner results. for the record, here's the contents of my imagemagick include, yours should look similar. good luck.. -- $ find /usr/include/ImageMagick /usr/include/ImageMagick /usr/include/ImageMagick/wand /usr/include/ImageMagick/wand/magick-property.h /usr/include/ImageMagick/wand/drawing-wand.h /usr/include/ImageMagick/wand/composite.h /usr/include/ImageMagick/wand/display.h /usr/include/ImageMagick/wand/compare.h /usr/include/ImageMagick/wand/magick-image.h /usr/include/ImageMagick/wand/MagickWand.h /usr/include/ImageMagick/wand/pixel-wand.h /usr/include/ImageMagick/wand/mogrify.h /usr/include/ImageMagick/wand/magick_wand.h /usr/include/ImageMagick/wand/convert.h /usr/include/ImageMagick/wand/animate.h /usr/include/ImageMagick/wand/stream.h /usr/include/ImageMagick/wand/montage.h /usr/include/ImageMagick/wand/pixel-iterator.h /usr/include/ImageMagick/wand/pixel-view.h /usr/include/ImageMagick/wand/conjure.h /usr/include/ImageMagick/wand/identify.h /usr/include/ImageMagick/wand/deprecate.h /usr/include/ImageMagick/wand/import.h /usr/include/ImageMagick/wand/magick-wand.h /usr/include/ImageMagick/Magick++ /usr/include/ImageMagick/Magick++/Include.h /usr/include/ImageMagick/Magick++/Pixels.h /usr/include/ImageMagick/Magick++/Drawable.h /usr/include/ImageMagick/Magick++/STL.h /usr/include/ImageMagick/Magick++/Image.h /usr/include/ImageMagick/Magick++/Geometry.h /usr/include/ImageMagick/Magick++/CoderInfo.h /usr/include/ImageMagick/Magick++/Montage.h /usr/include/ImageMagick/Magick++/Color.h /usr/include/ImageMagick/Magick++/TypeMetric.h /usr/include/ImageMagick/Magick++/Exception.h /usr/include/ImageMagick/Magick++/Blob.h /usr/include/ImageMagick/magick /usr/include/ImageMagick/magick/delegate.h /usr/include/ImageMagick/magick/option.h /usr/include/ImageMagick/magick/hashmap.h /usr/include/ImageMagick/magick/memory_.h /usr/include/ImageMagick/magick/signature.h /usr/include/ImageMagick/magick/resample.h /usr/include/ImageMagick/magick/feature.h /usr/include/ImageMagick/magick/locale_.h /usr/include/ImageMagick/magick/MagickCore.h /usr/include/ImageMagick/magick/magick-type.h /usr/include/ImageMagick/magick/composite.h /usr/include/ImageMagick/magick/display.h /usr/include/ImageMagick/magick/magic.h /usr/include/ImageMagick/magick/compare.h /usr/include/ImageMagick/magick/histogram.h /usr/include/ImageMagick/magick/gem.h /usr/include/ImageMagick/magick/distort.h /usr/include/ImageMagick/magick/fourier.h /usr/include/ImageMagick/magick/pixel.h /usr/include/ImageMagick/magick/shear.h /usr/include/ImageMagick/magick/mime.h /usr/include/ImageMagick/magick/decorate.h /usr/include/ImageMagick/magick/artifact.h /usr/include/ImageMagick/magick/blob.h /usr/include/ImageMagick/magick/quantum.h /usr/include/ImageMagick/magick/configure.h /usr/include/ImageMagick/magick/threshold.h /usr/include/ImageMagick/magick/fx.h /usr/include/ImageMagick/magick/coder.h /usr/include/ImageMagick/magick/resize.h /usr/include/ImageMagick/magick/methods.h /usr/include/ImageMagick/magick/policy.h /usr/include/ImageMagick/magick/magick.h /usr/include/ImageMagick/magick/utility.h /usr/include/ImageMagick/magick/segment.h /usr/include/ImageMagick/magick/log.h /usr/include/ImageMagick/magick/xwindow.h /usr/include/ImageMagick/magick/semaphore.h /usr/include/ImageMagick/magick/colormap.h /usr/include/ImageMagick/magick/random_.h /usr/include/ImageMagick/magick/transform.h /usr/include/ImageMagick/magick/registry.h /usr/include/ImageMagick/magick/animate.h /usr/include/ImageMagick/magick/magick-config.h /usr/include/ImageMagick/magick/compress.h /usr/include/ImageMagick/magick/client.h /usr/include/ImageMagick/magick/splay-tree.h /usr/include/ImageMagick/magick/cache.h /usr/include/ImageMagick/magick/colorspace.h /usr/include/ImageMagick/magick/paint.h /usr/include/ImageMagick/magick/matrix.h /usr/include/ImageMagick/magick/constitute.h /usr/include/ImageMagick/magick/stream.h /usr/include/ImageMagick/magick/cache-view.h /usr/include/ImageMagick/magick/list.h /usr/include/ImageMagick/magick/montage.h /usr/include/ImageMagick/magick/accelerate.h /usr/include/ImageMagick/magick/type.h /usr/include/ImageMagick/magick/version.h /usr/include/ImageMagick/magick/profile.h /usr/include/ImageMagick/magick/exception.h /usr/include/ImageMagick/magick/ImageMagick.h
Re: [PD] compiling pd-extended on arch linux
Hi dmotd, thanks for the link. I tried the PKGBUILD and it fails at exactly the same point. I already have imagemagick installed and Magickk++.h is in /usr/include/ImageMagick If i change Gem/src/Base/GemPixImageLoad.cpp line 64 from: # include to: # include it gets past the original error, but fails with the following error: In file included from GemPixImageLoad.cpp:64:0: /usr/include/ImageMagick/Magick++.h:9:30: fatal error: Magick++/Include.h: No such file or directory compilation terminated. So now it can't find Include.h, but Include.h is definitely located here: /usr/include/ImageMagick/Magick++/Include.h Must be something to do with paths right? How to I solve this? James Quoth dmotd, on 05/07/10 14:30: hi james, there's a PKGBUILD already available on AUR.. http://aur.archlinux.org/packages.php?ID=22509 tested very recently.. btw, you are missing imagemagick 'pacman -S imagemagick' should do the trick. dmotd James Dunn wrote: Hi list, I am trying to compile pd-extended on arch linux according to the instructions here: http://puredata.info/docs/developer/GettingPdSource I checked out svn and follwed the instructions here: http://puredata.info/docs/ developer/BuildingPdExtended make install fails with: GemPixImageLoad.cpp:64:23: fatal error: Magick++.h: No such file or directory compilation terminated I have ImageMagick installed and Magick++.h is in /usr/include/ImageMagick/ as well as /usr/local/include/ImageMagick Do I have to modify my path or something? thanks James ___ 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] software license for pd general patch?
when you put out a new version of gridflow, there are several replies from people that try it out, etc etc. that point was more about the "general interest of the comunity" argument. in any case it's good you don't get that many complaints, which shouldn't mean that there are less users. Generally speaking, pd-extended made a huge difference in the history of pd-list, that caused a large reduction of "can't compile" posts, and this decreased the apparent activity of pd-list, because message-count as a measure of community activity is about as meaningful as counting how many lines of source code. (well, perhaps a bit more on average, but there are simple ways to make it lie.) exactly, that's a great merit. that's why I always ask someone who hasn't put their code in there if he wants to - it makes it much more centralised, and easier to access. When I put my abstractions out, I get no reply at all. I guess it's safe to say that there is more interest in the pd list for gridflow than for some small abstractions, right? Hey, I thought that they were big abstractions, aren't they ? this isn't part of my abstractions (at /extra/jmmmp), it's a "full program". it doesn't come with pd-ext, it's on my pd page. I would say that it's as big as all my abstractions together, but never measured it. Well, despite its potential far-reaching consequences as a tool for designing pd patches about anything, gridflow is still almost only seen as a video tool you only start to look at when you get tired of trying to do something with GEM's [pix]. That somewhat limits the potential of it. Is the next time I try to update my object list (you might know the "short version" from the floss manual, the original is an xls file), I would try to include a list of the gridflow objects. I had started talks with a friend that does data visualisation to make a patch to automatise the listing, but he bailed out. so I have to do the work by hand. there something in your abstractions' concept, and the way you write about them, that limits their potential because most of its potential users don't recognise the contents of your summary of what it's for ? I don't have an idea what a click-track is, but I bet I could find a use for it anyway. my jmmmp abstractions are very simple utilities, most of them to spare some repetitive code (snaps~, metrum, ...). therefore, it's very simple to say in one line what they're supposed to do. of course, that doesn't stop anyone to go there, grab the code and use it somewhere else. for click track look http://en.wikipedia.org/wiki/Click_track. in case you're interested in them (if you don't want just to do 10m of 4/4), then my patch might be useful for you. or if you have any complaints/sugestions, I always want to know how to do it better. but that goes back to the initial point: this program was made for persons that play complex music from score, and can need the help of a click track system that lets them reherase/play in concert. that's why I said in the beginning that in this list almost anyone fits into that category, and I won't try to push it into them, just because I find it a useful tool. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] software license for pd general patch?
On Mon, 5 Jul 2010, João Pais wrote: I'm not excluding anyone, or criticising "the community" (not a good term, but I brought it up). If I would be critisicing anyone, it would be me, for not having the same interests as the majority. Do you understand that NO-ONE here has the same interests as the majority of those who are here ? not exactly the same, Whatever is "here". Let's say that it's not pd-list, but instead, the whole of pd production that gets published as free software. You'd reach the same conclusions very quickly. when you put out a new version of gridflow, there are several replies from people that try it out, etc etc. That's not much of a sign. There were times in which I was receiving more mail than that, while GridFlow was relatively unusable (in comparison to today). More generally, I made some stats on pd-list activity and then I thought about what facts make those figures not interesting, because I don't want to count the posts, I want to measure activity and such. I didn't go much farther, but I did think about the countless posts about how to compile Pd, especially as for a loong time it wasn't even possible to compile Pd without editing the Makefile, because of "-Werror". You can bet that there are situations in which you can increase the mail flow by having no consideration for the users whatsoever. ;) If you read the archives and look for all the places that say "just remove Werror" or "get rid of Werror" or pretty much any sentence with "Werror" in it, you'll see what I mean. It's all over 2003 and 2004. Generally speaking, pd-extended made a huge difference in the history of pd-list, that caused a large reduction of "can't compile" posts, and this decreased the apparent activity of pd-list, because message-count as a measure of community activity is about as meaningful as counting how many lines of source code. (well, perhaps a bit more on average, but there are simple ways to make it lie.) When I put my abstractions out, I get no reply at all. I guess it's safe to say that there is more interest in the pd list for gridflow than for some small abstractions, right? Hey, I thought that they were big abstractions, aren't they ? Well, despite its potential far-reaching consequences as a tool for designing pd patches about anything, gridflow is still almost only seen as a video tool you only start to look at when you get tired of trying to do something with GEM's [pix]. That somewhat limits the potential of it. Is there something in your abstractions' concept, and the way you write about them, that limits their potential because most of its potential users don't recognise the contents of your summary of what it's for ? I don't have an idea what a click-track is, but I bet I could find a use for it anyway. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] interface/pd-based standalone applications question
On Sun, 4 Jul 2010, chrism wrote: I have no idea. I just meant that if anyone deserves to be cooked meals because of Pd related things, then it's Miller. That is a lot of lines of source code (only 25,000 of them are portaudio/portmidi). First of all, if you consider portaudio and portmidi like the separate projects that they are and that Miller didn't write and that is not really part of Pd in any way, the total SLOC drops to 68000. Next, Miller is not completely alone in writing Pd. You probably know that already. It's not even a very small or neglectible amount. In SLOC count, Thomas Musil contributed 10% of the source code alone, as the original author of the IEMGUI library. Then you probably know what is copy-paste. IIRC, about 1300 lines of code of IEMGUI can be explained by a one-liner sed | diff | wc command. Then there is other copy-paste in places like d_math.c and x_arithmetic.c for which I made the demonstration that they can be shrunk to less than 20% of their size using macros *while* keeping all optimisations in. (not sure I posted on the lists about it, though). Then the "basic COCOMO model" does not take copy-paste into account, therefore it's naïve at best, a fraud at worst. It's also highly dependent on many other things it shouldn't be dependent on, thus it's most certainly unlikely to be accurate at all. Braces change the SLOC. The 72-character maximum that comes from IBM punchcards) changes the SLOC. Statement size changes the SLOC (say something short as two statements, you have two lines, but say it as one, you have one line). Think about it, you even charge for the blank lines and all the lines that say // , no matter how many a given programmer decides to put. All the Basic COCOMO model ever does correctly is punish any people who try to save on the number of lines of code. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] compiling pd-extended on arch linux
hi james, there's a PKGBUILD already available on AUR.. http://aur.archlinux.org/packages.php?ID=22509 tested very recently.. btw, you are missing imagemagick 'pacman -S imagemagick' should do the trick. dmotd James Dunn wrote: > Hi list, > > I am trying to compile pd-extended on arch linux according to the instructions > here: http://puredata.info/docs/developer/GettingPdSource > I checked out svn and follwed the instructions here: > http://puredata.info/docs/ > developer/BuildingPdExtended > > make install fails with: > > GemPixImageLoad.cpp:64:23: fatal error: Magick++.h: No such file or directory > compilation terminated > > I have ImageMagick installed and Magick++.h is in /usr/include/ImageMagick/ as > well as /usr/local/include/ImageMagick > Do I have to modify my path or something? > > thanks > > James > ___ > 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] Playing and recording simultaneously
Mathieu Bouchard wrote: On Sun, 4 Jul 2010, Martin Peach wrote: As long as they are on the same card, they will be in perfect sync at the clock level unless you have some really unusual hardware. This is because the same clock is used for A/D and D/A. Usually they are on the same chip and the data from the ADC is clocked out using the same clock that loads the DAC. Can you just explain to us why sync has to be done when you have two soundcards that are supposed to be sending you the same number of blocks per second ? ? I mean, for example, suppose a soundcard that is nominally set at 44100 Hz is actually running at 44098 Hz ; then what happens to Pd objects that depend on the samplerate (such as [osc~], [lop~], etc) ? Do they use 44098, or 44100 ? that would be the same as whatever [samplerate~] says, but somehow, it always says exactly 44100.000 ... why ? Is it because my soundcard's clock is that much accurate ? (it's a cheap on-board thing) The sample rate is set by the frequency of the crystal on the card, which is supposed to run at some multiple of 44100 or 48000, but that's set by the manufacturing tolerances and nothing is actually measuring it. Also because the crystal changes in size with temperature the frequency will change slightly as it warms up. Precision oscillators are kept inside ovens for that reason. Pd assumes 44100Hz even if the card isn't doing that. (Some of the code seems to be actually hard-wired for 44100). For instance if I clock one sound card with the SPDIF output of another card on another machine that's running at 22050Hz, the test tone is 220Hz instead of 440 and Pd is none the wiser. I recall seeing precisely "44098 Hz" when my soundcard was an ISA Ultrasound (Gravis) some 5-10 years ago, but I don't recall whether it was at Pd's startup, another programme's startup, or both. I guess if you know the CPU frequency you can count samples to determine the sample rate, but that assumes that the CPU clock is what it says it is. Relativity and all that... Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] GEM pix_film crashing on OSX 10.5
On Mon, 5 Jul 2010, Julio Terra wrote: The crash often happens all by itself (e.g. no input is being processed by the patch at the time of the crash). The video you are playing is a kind of input in some manner (though it's also useful to know that you're not having any other input than that). First, check out the Load Meter patch (in the Media menu) and make sure that the number doesn't increase over time. (though usually, it wouldn't make the sound disappear suddenly) Then, there's a system programme that allows you to check how much RAM the programmes (.app and others) are using. PureData is represented by two entries. Make sure that there isn't one that inflates like crazy over time. Also make sure the CPU doesn't grow over time (Load Meter only reports one of the CPU values and doesn't tell you about the other entry). Then later, check whether it makes a difference whether the result of [pix_film] is used at all : try disconnecting [pix_texture] but keep [gemhead] active. If you still don't find a difference, try the [pix_film] test with a reencoding of your video file in a different codec. Do you use [vline~] at all, in your audio part ? _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] compiling pd-extended on arch linux
Hi list, I am trying to compile pd-extended on arch linux according to the instructions here: http://puredata.info/docs/developer/GettingPdSource I checked out svn and follwed the instructions here: http://puredata.info/docs/developer/BuildingPdExtended make install fails with: GemPixImageLoad.cpp:64:23: fatal error: Magick++.h: No such file or directory compilation terminated I have ImageMagick installed and Magick++.h is in /usr/include/ImageMagick/ as well as /usr/local/include/ImageMagick Do I have to modify my path or something? thanks James ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] interface/pd-based standalone applications question
can you put a better guide somewhere on how to do these things? when you say "check out the code" it's something any of you guys do with your eyes closed, and it takes me almost 1h to understand why anything is working. I also don't know what is a diff. Good idea. Sorry for my presumption. it's not presumption, that's common language to most of you guys. but for any (not just me) who would like to do something (and sometimes can), it's not easy to decypher. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
