Pd Vanilla only has one way to do that-- exploit the inconsistency in dollsymarg and dollararg expansion for non-existent abstraction arguments.

For example-- suppose our parent abstraction is [foo 0]. Inside that abstraction we try [list append $1] which gives "0". We also try [list append $1-sym] which gives "0-sym". But we don't know if that means the abstraction arg was zero or there was no abstraction arg given.

So let us try abstraction [foo] with no args. Now inside foo we create [list append $1] which again gives us "0". That's no help at all. But now look at the output from [list append $1-sym]:

symbol \\$1-sym

When "$1" doesn't exist, Pd's string concatenation algorithm doesn't expand the dollararg to 0 but instead quotes it directly. Weird.

So now we've got an algorithm for finding the length of the list of args, which consequently means we can reproduce that list of args inside the abstraction:

(pseudocode)
check if [list append $1]--[$1-sym( is equal to [list append $1-sym]
if it isn't then you've got one less arguments than the dollararg you tried.
if it is equal then "add2" the value of the dollararg into a msg box and try with the next biggest dollarsign variable
...
at the end, bang out the msg box to get the full list of args

Notice that you must do this inside the canvas or subcanvas where you want to get the arguments. So you cannot modularize this algorithm inside an abstraction-- you must always paste a subpatch inside the relevant abstraction.

Or in Purr Data you can just do this:

[list append $@]

or this:

[args(
|
[canvasinfo]

Perhaps we can create a new thread about C optimizations for real time audio.

I would appreciate that, although I wouldn't be much of a help.

I can't recreate the error, are you sure you use the object compiled with the last version of the code. Sometimes on Windows, you really need to clean the project before compiling otherwise the modifications are not taken into account.

I used your updated code, cleaned and rebuilded the project. Still get exceptions, with and without optimizations.
After some exceptions I sometimes have to restart the computer, as pd reacts strange on restarting the debugger.
As I said, I'm new to C and therefore to compiling as well.
I'm on win7, pd 0.47.1, Virtual Studio 2017 RC

I tried to follow your advise and implemented the average with one large vector. But I get errors as well - VS tells me, symbols are missing, but doesn't point me to a specific line.
My code is here:
https://github.com/XRoemer/puredata/blob/master/average~/C/r_average~2 -not working.h
EDIT2:
I made a stupid mistake: forgot to reallocate the avg array. I'll update the code.

EDIT:
I had to leave out EXTERN on meanblock_tilde_setup, as I couldn't compile with it. But I guess this is for CPP only, isn't it?
Also I compiled your meanblock as meanblock.h and not as meanblock.c

try taking away -Werror or adding -Wno-unused-parameter in the makefile CFLAGS. -Wno-unused doesn't seem to work, The issue is that pd uses certain patterns for calling functions, so devs include arguments in functions that aren't used all the time. This is supposed to result in a warning. However, -Werror makes warnings into errors (so it doesn't compile). -Wno-unused is probably meant to ignore unused variables (counteract -Wunused-parameter) but doesn't seem to work that way

Hello,

I'm new here, new to pure data and also a noob in general when it comes to terminal command line etc. i have used pure data years ago but never dug deep enough. For a (eventually raspberry pi) project i need to set up fftease on intel mac (for now) and possible other library's as well. compiling these extensions seems like a good skill, i dont want to rely on others that have done it for me, but if there is a fftease 2.5.2 64 compiled version somewhere, please point me to it as i could not find it.

After trying to get fftease working i realised that i was doing the right thing with the {declare} object but was doing it with 32bit bin files on 64bit Pd, after i downloaded 32bit Pd everything seems to work.

What i'm asking myself is, is it a good idea to run 32 pure data on a 64bit intel mac? i may (or possible user error) already run into some problems.

How do i compile fftease 32bit files to 64bit bin in the terminal and should i only compile the .dll files? i have searched stack overflow etc. but i could not find a straight answer.

Thanks for reading

...in assembling a Big Picture I took time to focus on a small one.

I compiled (really just for kicks to see how hard it was to compile something) the "Audio Patches for the OpenWareLaboratory" at https://github.com/pingdynasty/OwlPatches (only the Faust folder) using the Faust Compiler at http://faust.grame.fr/compiler/.

OwlPatches.zip

They seem to be real bare bones but would be cool to make a straight forward sort of plaY-as-you-go guitar-rack. (I don't much else about them except they are basic guitar effects.)

-peace

svanya

p.s. having gotten my first taste of compiling something, I can see why people like it.

Hello all,

After a few weeks of reading, researching, and attempting to find a reliable way to compile externals, I have most simple cases working such as the tutorial objects found from the IEM tutorials and Eric Lyon's book on the subject.

However, trying to compile Oggread~ from the pdogg library (https://goo.gl/WvPLnW) results in an external that fails to load in PD, throwing the error:

"oggread~.pd_darwin: dlopen(/path/to/external/oggread~.pd_darwin, 10): symbol not found: _ov_bitrate referenced from: /path/to/external/oggread~.pd_darwin
Expected in: flat namespace"

the reference to ov_bitrate is contained in vorbisfile.h, and as far as I can tell, has been linked and compiled correctly.

I hate to ask for help from a community I've just joined, but I've been struggling with this for a few weeks on my own to no avail, so absolutely any insight or help would be appreciated.

I've uploaded the files in question below. The compiled external can be found in the build folder, and all vorbis/ogg header files can be found in the libs folder.

oggread~ compilation.zip

Thank you,
James

Hi,
I wanted to use the [NLMS~] and [nlms2~] externals, but they seems to be missing on the pd-extended for Windows (they turn into a red box).
I wanted to compile the iem_adaptfilt sources but they're only supplied with makefiles which are quite useless on widows. I use cygwin but it's make doesn't seem to like the makefiles as it doesn't recognize a single word. Any other way to compile these sources under win?
Or are there adaptive filters already included in PD-extended?

Hello everyone!

First of all, I'd like to introduce myself. My name is Ariel and i'm from Argentina. I study composition using electroacoustic methods. We had a subject on max programing and I've recently switched to PD. Unfortunately, I don't own a Mac and work on Windoze. So you can already figure why I'm looking for support, ha.

Well, I'm trying to make an interface from a generic usb joystick to send midi messages; nothing complicated. HOWEVER, [hidin] seems to dislike my joystick and won't recognize buttons nº 1 to 8. It does recognize de arrows, analogs, select, start and the analog buttons.

I downloaded the external [joystick] but, guess what? It recognizes everyhing else BUT not the arrows.

I'm trying to keep the patch as simple as possible, so I'd love to make [hidin] work. Besides, when I choose the joystick from the available HIDs in [hidin], it says it has 44 inputs, but it only recognizes a few (listed above).

As you can see, from my experience with [joystick], all the buttons actually work (I've also tested it on games). So I can't figure out why [hidin] isn't recognizing some of them.

I hope you guys can help me! I'd really appreciate it!

Yours sincerely,

Ariel.

P.S: Please excuse my terrible english.

_
_ _ ____ _ _ ||
| | | | ||_ | | || | |
| || | | || | | ||| | |_____
| | || | | | ____ | | | | |
| | | | | | | | | | || | |_
|| || || || || || ||
|| ____ _______ _________
|| || | | | | _
| || | | ||| | | || ||
from | __ | | _ | | |
4 to 7 | | | | | | ||__ ||
NOVEMBER 2010 || || || |_| ||

*CALL FOR PROJECTS*

The sixth edition of make art – in-between design: rediscovering
collaboration in digital art – will take place in Poitiers (FR), from
the 4th to the 7th of November 2010.

make art is an international festival dedicated to the integration
of Free/Libre/Open Source Software (FLOSS) in digital art.
make art offers performances, presentations, workshops and an
exhibition, focusing on the encounter between digital art and free
software.

*in-between design: rediscovering collaboration in digital art*

Today's market production accelerates the spread of non-critical and
standardized aesthetics, by means of locked top-down distribution
mechanisms and a series of tools that enforce it. At the same time
new forms of methodologies inspired or powered by free software,
participatory practices and peer-to-peer networks are fueling many
Internet subcultures. Some of these emerging practices will lead to
competitive social productions, while other will remain as pure
artistic experiments.

By adopting production and distribution methods based on free software
and open standards and by sharing the sources of one's work with
others, the collective knowledge base and aesthetic sensibilities can
freely interact to explore uncharted, hybrid directions which no
longer reflect the supremacy of a single idea.

• Does the sharing of artworks "recipes" and tools help debunk
  the myth of the isolated design genius?
• By leaving the possibility of ongoing development and refinement,
  is it possible to ever produce a "final" design?
• Can these methods and technologies inspire new forms of creation or
  tools, beyond self-referential productions?
• Is it wishful thinking to approach collaborative graphical design
  in the same way as an open source software project?
• Is Free and Open Source licensing a catalyst for creation or does
  it add an extra level of complexity?
• Can the limitation of one license trigger new forms of constrained
  creativity?

We're currently seeking new, innovative media art and design works and
projects focusing on the above theme and questions:

• graphical artworks and installations
• lectures
• project presentations
• software and hardware demos

We're also seeking audiovisual performances that will take place
during the festival evenings.

The submitted projects must fit this focus and be made in a free/libre
and open source environment, this includes both its optional
dependencies or production tools and the operating system. We are
asking you to publish the sources of your project under a free culture
license of your choice or release it into the public domain.
Projects that do not meet these criteria will not be considered.

*How to apply*

Submission form and a list of additional requirements are available at:
http://makeart.goto10.org/call/

Deadline: *Saturday 31 July 2010*

Incomplete or late applications will not be processed.

*Timeline*

31st of July 2010 – Deadline call for proposals
Beginning of September – Selected projects notifications
4th-7th of November 10 – make art 2010 - Poitiers (FR)

For examples of previous editions, please visit the archives :
http://makeart.goto10.org/

make art is powered by GOTO10

[tim@vosto src]$ uname -a
Linux vosto 2.6.33.5-124.fc13.x86_64 #1 SMP Fri Jun 11 09:38:12 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux
[tim@vosto src]$ cd /pd/src
[tim@vosto src]$ ./configure
bash: ./configure: No such file or directory
[tim@vosto src]$ sudo autoconf

[tim@vosto src]$ sudo ./configure
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for a BSD-compatible install... /usr/bin/install -c
checking whether make sets $(MAKE)... yes
checking how to run the C preprocessor... gcc -E
checking for an ANSI C-conforming const... yes
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for pid_t... yes
checking for size_t... yes
checking whether time.h and sys/time.h may both be included... yes
checking for ANSI C header files... (cached) yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking malloc.h usability... yes
checking malloc.h presence... yes
checking for malloc.h... yes
checking sys/ioctl.h usability... yes
checking sys/ioctl.h presence... yes
checking for sys/ioctl.h... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking for unistd.h... (cached) yes
checking bstring.h usability... no
checking bstring.h presence... no
checking for bstring.h... no
checking io.h usability... no
checking io.h presence... no
checking for io.h... no
checking whether gcc needs -traditional... no
checking return type of signal handlers... void
checking for vprintf... yes
checking for _doprnt... no
checking for gettimeofday... yes
checking for select... yes
checking for socket... yes
checking for strerror... yes
checking for working alloca.h... yes
checking for alloca... yes
checking for dlopen in -ldl... yes
checking for sin in -lffm... no
checking for sin in -lm... yes
checking for pthread_create in -lpthread... yes
checking tcl.h usability... yes
checking tcl.h presence... yes
checking for tcl.h... yes
checking for main in -ltcl85... no
checking for main in -ltcl8.5... yes
checking for main in -ltk85... no
checking for main in -ltk8.5... yes
.................... alsa= yes
checking for snd_pcm_info in -lasound... no
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... no
./configure: line 5767: syntax error near unexpected token `SINF,'
./configure: line 5767: `AST_EXT_LIB_CHECK(SINF, m, sinf)'

I can't solve this compilation error. Can anyone help?
I found a similar problem here: http://bbs.archlinux.org/viewtopic.php?id=86440
Unfortunately the planet CCRMA packages are quite fare behind the fedora releases, otherwise I'd use them.