hi
i tried to put some things into the devel_0_38 but couldn't really get it to work, and so it stopped being fun after a while (devel_0_38 currently does not load externals, and i didn't want to find out why)
however, to keep thomas musil from rewriting every single math~ object to our needs i have added another (over-simple) resampling method to pd0.38test8
the idea is as follows: when doing dsp on "fft-signals" it is often enough to do the calculations on only the first half of the signal-vector (as the information in the second half is redundant) to reduce cpu-load it might therefore be interesting to have objects, that only operate on the 1st half of the vector. no rewriting each object seems stupid to me, as pd can handle this way more simple;
the "block-downsampling" (i haven't come across a better name yet, but it is surely no "resampling") does as follows:
downsampling) only the first part of the original vector is copied 1:1 to the shorter result-vector; the rest is silently ignored upsampling) the shorter original vector is copied 1:1 to the longer result vector; the rest of the result is filled up with 0.
the attached patch modifies - m_pd.h (to use defines like "RESAMPLE_HOLD" rather than "1"; i consider this more readable and it was lazy for me in the first place to not have this in the original resampling) - g_io.c (to add another argument to the in/outlet~ functions: "block"; btw, i have changed the arg-parsing a bit to not use the symbol-table but rather decide on the first letter which resampling method to use) - d_resample.c (add the new resampling methods)
probably you could include this (i cannot watch thomas producing [+~2] objects)
only drawback: still uses arguments to inlet~/outlet~ to define behaviour instead of tooltips...
mfg.as.r IOhannes
i tried to put some things into the devel_0_38 but couldn't really get it to work, and so it stopped being fun after a while (devel_0_38 currently does not load externals, and i didn't want to find out why)
Works here no problem. (under Windows at least) The only problems that i encountered are GUI-related.. i'll try to report that later.
best greeting, Thomas
I don't know, whether this was discussed before, but I think the problem is, that only the first flag is passed as argument, all others are dropped for some reason.. marius.
----- Original Message ----- From: "Thomas Grill" gr@grrrr.org To: "pd-dev" pd-dev@iem.kug.ac.at Sent: Tuesday, November 09, 2004 6:30 PM Subject: Re: [PD-dev] resampling patch 0.38test8
i tried to put some things into the devel_0_38 but couldn't really get it to work, and so it stopped being fun after a while (devel_0_38 currently does not load externals, and i didn't want to find out why)
Works here no problem. (under Windows at least) The only problems that i encountered are GUI-related.. i'll try to report that later.
best greeting, Thomas
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
Sorry, I had some other mess with my starting skripts, seems to work now... marius.
----- Original Message ----- From: "Marius Schebella" marius.schebella@chello.at To: "Thomas Grill" gr@grrrr.org; "pd-dev" pd-dev@iem.kug.ac.at Sent: Tuesday, November 09, 2004 7:21 PM Subject: Re: [PD-dev] resampling patch 0.38test8
I don't know, whether this was discussed before, but I think the problem is, that only the first flag is passed as argument, all others are dropped for some reason.. marius.
----- Original Message ----- From: "Thomas Grill" gr@grrrr.org To: "pd-dev" pd-dev@iem.kug.ac.at Sent: Tuesday, November 09, 2004 6:30 PM Subject: Re: [PD-dev] resampling patch 0.38test8
i tried to put some things into the devel_0_38 but couldn't really get it to work, and so it stopped being fun after a while (devel_0_38 currently does not load externals, and i didn't want to find out why)
Works here no problem. (under Windows at least) The only problems that i encountered are GUI-related.. i'll try to report that later.
best greeting, Thomas
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
i tried to put some things into the devel_0_38 but couldn't really get it to work, and so it stopped being fun after a while (devel_0_38 currently does not load externals, and i didn't want to find out why)
you're on linux ... i don't have any problems running my externals compiled for 37 (devel) under 38 (devel) ... using the (i know, deprecated) .pdrc file ...
cheers ... tim
On Nov 9, 2004, at 4:11 PM, Tim Blechmann wrote:
i tried to put some things into the devel_0_38 but couldn't really get it to work, and so it stopped being fun after a while (devel_0_38 currently does not load externals, and i didn't want to find out why)
you're on linux ... i don't have any problems running my externals compiled for 37 (devel) under 38 (devel) ... using the (i know, deprecated) .pdrc file ...
Is the .pdrc deprecated on GNU/Linux as well? That's the first I've heard of this.
.hc
________________________________________________________________________ ____
"The arc of history bends towards justice." Dr. Martin Luther King, Jr.
The new "settings" mechanism is intended to replace the .pdrc mechanism... however, there are still enough problems with "settings" that it's frequently necessary to fall back on .pdrc.
cheers Miller
On Tue, Nov 09, 2004 at 05:55:11PM -0500, Hans-Christoph Steiner wrote:
On Nov 9, 2004, at 4:11 PM, Tim Blechmann wrote:
i tried to put some things into the devel_0_38 but couldn't really get it to work, and so it stopped being fun after a while (devel_0_38 currently does not load externals, and i didn't want to find out why)
you're on linux ... i don't have any problems running my externals compiled for 37 (devel) under 38 (devel) ... using the (i know, deprecated) .pdrc file ...
Is the .pdrc deprecated on GNU/Linux as well? That's the first I've heard of this.
.hc
"The arc of history bends towards justice." Dr.Martin Luther King, Jr.
you're on linux ... i don't have any problems running my externals compiled for 37 (devel) under 38 (devel) ... using the (i know, deprecated) .pdrc file ...
Is the .pdrc deprecated on GNU/Linux as well? That's the first I've heard of this.
miller was talking about replacing it with a pd-settings file ... haven't checked the code though ...
tim
Ok, what I found out is, that, different as in earlier versions, Pd cannot handle more than one spaces between flags. pd -lib blabla -lib bloblo is ok, but pd -lib blabla -lib bloblo will not work. marius.
----- Original Message ----- From: "Tim Blechmann" TimBlechmann@gmx.net To: "Hans-Christoph Steiner" hans@eds.org Cc: "Johannes M Zmoelnig" zmoelnig@iem.at; "pd-dev" pd-dev@iem.kug.ac.at; msp@ucsd.edu Sent: Wednesday, November 10, 2004 10:29 AM Subject: Re: [PD-dev] resampling patch 0.38test8
you're on linux ... i don't have any problems running my externals compiled for 37 (devel) under 38 (devel) ... using the (i know, deprecated) .pdrc file ...
Is the .pdrc deprecated on GNU/Linux as well? That's the first I've heard of this.
miller was talking about replacing it with a pd-settings file ... haven't checked the code though ...
tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
Hallo, Marius Schebella hat gesagt: // Marius Schebella wrote:
Ok, what I found out is, that, different as in earlier versions, Pd cannot handle more than one spaces between flags. pd -lib blabla -lib bloblo is ok, but pd -lib blabla -lib bloblo will not work.
I wonder: Couldn't Pd use some of the many standard option handling libraries like GNU getopt?
Ciao
On Wed, 10 Nov 2004, Frank Barknecht wrote:
Ok, what I found out is, that, different as in earlier versions, Pd cannot handle more than one spaces between flags. pd -lib blabla -lib bloblo is ok, but pd -lib blabla -lib bloblo will not work.
I wonder: Couldn't Pd use some of the many standard option handling libraries like GNU getopt?
I haven't tried GNU getopt but I must say that I'd favour a more table-oriented system of options in general. For example, the pdrc editor of impd_0_37 uses a list-of-lists in Tcl in which each row is a (name,type,comment) triple. Even though that part of the code is essentially dead, the concept may be recycled to handle the commandline options. What is missing is a callback field so that each detected option can trigger a particular piece of code. This may be cumbersome to do in C, but if we use Pd messages instead of function-pointers, then we get the reward that all (or most) commandline options would be runtime-settable. Imagine this kind of global message:
[; pd path /home/dude/pd-patches (
But prolly (for a start) that many of those methods would only be guaranteed to work at load-time. "path" would be one of those available all of the time.
(I recall making that kind of suggestion in Graz, prolly during the impd talk)
_____________________________________________________________________ Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
Ok, what I found out is, that, different as in earlier versions, Pd cannot handle more than one spaces between flags. pd -lib blabla -lib bloblo is ok, but pd -lib blabla -lib bloblo will not work. marius.
That's an easy fix as it seems: obviously in s_entry.c the tokenizeCommandLineString function doesn't work right. However, the Windows command line arguments are already preparsed by the C library and can be accessed via __argc and __argv. Attached is a corrected version. I'll post a patch.
best greetings, Thomas
----- Original Message ----- From: "Tim Blechmann" TimBlechmann@gmx.net To: "Hans-Christoph Steiner" hans@eds.org Cc: "Johannes M Zmoelnig" zmoelnig@iem.at; "pd-dev" pd-dev@iem.kug.ac.at; msp@ucsd.edu Sent: Wednesday, November 10, 2004 10:29 AM Subject: Re: [PD-dev] resampling patch 0.38test8
you're on linux ... i don't have any problems running my externals compiled for 37 (devel) under 38 (devel) ... using the (i know, deprecated) .pdrc file ...
Is the .pdrc deprecated on GNU/Linux as well? That's the first I've heard of this.
miller was talking about replacing it with a pd-settings file ... haven't checked the code though ...
tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
At this stage I would like to suggest the ability to store multiple groups of settings in the setting mechanism so that one PD can switch between different configurations.
Otherwise I'm still going to be using shell aliases with command-line options.
B.
Tim Blechmann wrote: |>>you're on linux ... i don't have any problems running my externals |>>compiled for 37 (devel) under 38 (devel) ... |>>using the (i know, deprecated) .pdrc file ... |> |>Is the .pdrc deprecated on GNU/Linux as well? That's the first I've |>heard of this. | | miller was talking about replacing it with a pd-settings file | ... haven't checked the code though ... | | tim |
Tim Blechmann wrote:
you're on linux ... i don't have any problems running my externals compiled for 37 (devel) under 38 (devel) ... using the (i know, deprecated) .pdrc file ...
true i am on linux.
1. i do a "cvs update -P -d -r devel_0_38" in pd 2. i try to compile this does not work because the simd-files are not included within the makefile; so i add them 3. i compile (ignoring some warnings about static functions being not static) 4. i start pd and try to load [zexy] (which loads perfectly well with pd-0.38test8 and pd-0.36 and ...) 5. it complains: + tried /usr/local/lib/pd/extra/zexy.pd_linux and succeeded + load_object: Symbol "zexy_setup" not found 6. i load [fiddle~]; pd complains: + tried ../extra/fiddle~/fiddle~.pd_linux and succeeded + load_object: Symbol "fiddle_tilde_setup" not found
while "zexy" is not compiled against devel_0_38, "fiddle~" certainly is; so i still think this is broken
mfg.asd.r IOhannes
Johannes M Zmoelnig wrote:
Tim Blechmann wrote:
you're on linux ... i don't have any problems running my externals
so i still think this is broken
mea culpa (?)
i have done a complete fresh checkout on my home machine and now it works...
mfg.as.dr IOhannes
you're on linux ... i don't have any problems running my externals
so i still think this is broken
mea culpa (?)
i have done a complete fresh checkout on my home machine and now it works...
hm ... although i try to keep the original build system up to date, i suggest to use the autobuild system (i'm working with that and trying to maintain it for linux) ...
cheers ... tim
Johannes M Zmoelnig wrote:
hi
and of course i had added one comment after my last compile, andthat comment happened to break everything (unbalanced /* */)
anyhow, this one should work now as expected (and the code for linear upsampling has improved a little bit...)
mfg.asd.r IOhannes
Johannes M Zmoelnig wrote:
hi
i tried to put some things into the devel_0_38 but couldn't really get it to work, and so it stopped being fun after a while
well, i have now managed to check the new re-sampling method into devel_0_38
furthermore i have committed a patch that allows to set the blocksize of the dac to some arbitrary (2^n) length instead of 64 samples. this should enable some lower latencies. i was only able to test it on linux so far; probably it will not work out of the box on other OSs.
mfg.a.sdr IOhannes
furthermore i have committed a patch that allows to set the blocksize of the dac to some arbitrary (2^n) length instead of 64 samples. this should enable some lower latencies. i was only able to test it on linux so far; probably it will not work out of the box on other OSs.
s_audio_pa.c won't compile with msvc any more ... i suppose msvc doesn't support variable sized arrays ...
cheers ... tim
Tim Blechmann wrote:
s_audio_pa.c won't compile with msvc any more ... i suppose msvc doesn't support variable sized arrays ...
ah, sh*t...
isn't there any possibility to get variable sized arrays withing msvc ?
mfg.asd.r IOhannes
ah, sh*t...
isn't there any possibility to get variable sized arrays withing msvc ?
Not to my knowledge. In such cases i always assign some (probably oversized) static/auto memory for the most common array sizes and do dynamic allocation for the rest.
best greetings, Thomas
On Wed, 17 Nov 2004, Thomas Grill wrote:
ah, sh*t... isn't there any possibility to get variable sized arrays withing msvc ?
Not to my knowledge. In such cases i always assign some (probably oversized) static/auto memory for the most common array sizes and do dynamic allocation for the rest.
Actually, the variable-size stack-allocated arrays of GNU C is "syntactic sugar" over a function called alloca(size) that does just the same. However that function is not ANSI, not ISO and not even POSIX. It seems to be rather confined to BSD & Linux.
Maybe I should stop my wanton use of that feature (i use the GNU C/C++ syntax, not alloca itself), because several systems (Ruby,Pd) are eager to complain when the current stack content just _appears_ to be too big, because that's how they detect an infinite recursion (!!!), so they tend to choke when I put several *video frames* on the stack. :-]
_____________________________________________________________________ Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
Tim Blechmann wrote:
s_audio_pa.c won't compile with msvc any more ... i suppose msvc doesn't support variable sized arrays ...
after mathieu's (and some others') suggestion of using alloca() instead of float[] i have done so and committed the changes.
however i have no possibility to check whether this works on either windows nor osX, so please try to recompile it.
mfg.asd.r IOhannes
after mathieu's (and some others') suggestion of using alloca() instead of float[] i have done so and committed the changes.
however i have no possibility to check whether this works on either windows nor osX, so please try to recompile it.
haven't tried to compile ... but alloca() is supported by msvc ...
cheers ... tim
Tim Blechmann wrote:
after mathieu's (and some others') suggestion of using alloca() instead of float[] i have done so and committed the changes.
however i have no possibility to check whether this works on either windows nor osX, so please try to recompile it.
haven't tried to compile ... but alloca() is supported by msvc ...
yes i know i have hopefully included the correct header-files, blindfolded as i was...
mfg..asdr IOhannes
-
B. Bogart -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Johannes M Zmoelnig
-
Marius Schebella -
Mathieu Bouchard -
Matju
-
Miller Puckette -
Thomas Grill -
Tim Blechmann