---
** [bugs:#1148] Auto-patch causes [bang] to output twice**
**Status:** open
**Group:** v0.43
**Labels:** bang sel duplicate autopatch
**Created:** Thu Jun 12, 2014 06:29 PM UTC by Anonymous
**Last Updated:** Thu Jun 12, 2014 06:29 PM UTC
**Owner:** nobody
[sel]
|
[bang]
|
[symbol(
|
[print]
Prints the symbol twice, if the sequence is auto-patched. If done manually, no duplicate.
v0.43.4 extended, windows 7 x64, intel i7 cpu
---
Sent from sourceforge.net because pd-dev(a)lists.iem.at is subscribed to http://sourceforge.net/p/pure-data/bugs/
To unsubscribe from further messages, a project admin can change settings at http://sourceforge.net/p/pure-data/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
---
** [patches:#524] cmdline options to undo previous options**
**Status:** open
**Group:** bugfix
**Created:** Tue Jun 10, 2014 10:45 AM UTC by IOhannes m zmölnig
**Last Updated:** Tue Jun 10, 2014 10:45 AM UTC
**Owner:** Miller Puckette
currently, Pd has no way to disable a cmdline option. e.g. the flag **-noautopatch** disables the auto-patching feature, but there is no corresponding **-autopatch** flag.
similarily, on linux there is no way to switch to the default MIDI-API (*OSS*) once the *alsa*-API has been chosen (using the **-alsamidi** flag).
this is annoying in three cases:
- *partially overriding preferences:*
if the user added some flags to their preferences (e.g. to use alsa-MIDI as the default; or run in verbose mode), they cannot override these defaults on an ad-hoc basis without either completely disabling their preferences (using the **-noprefs** flag) or by modifying them (which they probably don't want to, as these are the settings they *prefer*)
- *scripts that call Pd with flags:*
some scripts (I use) call Pd with a number of flags that makes them fit for the target purpose (e.g. running on an embedded device, thuse using **-nogui**) and other wise pass cmdline args unchanged to Pd (e.g. the patch to open, the search-paths to use).
it is often desirable to be able to override one of these flags for testing purposes (e.g. starting up the GUI when running the script in an interactive session with X-Forwarding)
- *binaries with different defaults:*
sometimes binaries that pretend to be Pd-vanilla (like the Debian package "puredata") chose slightly different defaults (Debian uses *alsa* as the default MIDI-API, as this provides an out-of-the-box solution for much more people than *OSS*). how to restore the original "defaults"?
the attached patch adds a number of additional flags that negate previous settings (e.g. **-gui** to override a **-nogui** flag) when it seems to make sense.
i left out the **-prefs** flag (overriding a **-noprefs** option) mainly because this could be useful for specifying an alternative preferences-file (**-prefs /tmp/myotherprefs**).
---
Sent from sourceforge.net because pd-dev(a)lists.iem.at is subscribed to https://sourceforge.net/p/pure-data/patches/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pure-data/admin/patches/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
---
** [bugs:#1147] Puredata and sudo not starting UI.**
**Status:** open
**Group:** v0.43
**Created:** Mon Jun 09, 2014 08:35 PM UTC by Anonymous
**Last Updated:** Mon Jun 09, 2014 08:35 PM UTC
**Owner:** nobody
pd is not starting the UI, if started via "sudo -u XX puredata".
The problem seems to be that puredata tries to read configuration files from HOME/, which are then not accessible and thus startup stops.
What works is:
sudo -u XX bash
> export HOME=/tmp
> puredata
Sound devices are opened in both cases.
Details:
* Pd-0.45.4 ("") compiled 17:28:13 Dec 11 2013
* Ubuntu 14.04 64bit
* Linux x201 3.13.0-29-generic #53-Ubuntu SMP Wed Jun 4 21:00:20 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
---
Sent from sourceforge.net because pd-dev(a)lists.iem.at is subscribed to http://sourceforge.net/p/pure-data/bugs/
To unsubscribe from further messages, a project admin can change settings at http://sourceforge.net/p/pure-data/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
---
** [bugs:#1146] iemlib fails to build on linux using externals/Makefile**
**Status:** open
**Group:** v0.45
**Created:** Fri Jun 06, 2014 07:13 PM UTC by Anonymous
**Last Updated:** Fri Jun 06, 2014 07:13 PM UTC
**Owner:** nobody
I'm doing a custom build of several externals on Linux (Debian Wheezy arm hf on an Udoo board) using the externals Makefile and iemlib fails to build.
Adding the following to line 835 after $(CLFAGS) fixes this:
-I$(externals_src)/iemlib/include -fPIC
---
Sent from sourceforge.net because pd-dev(a)lists.iem.at is subscribed to http://sourceforge.net/p/pure-data/bugs/
To unsubscribe from further messages, a project admin can change settings at http://sourceforge.net/p/pure-data/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
---
** [patches:#523] build (parts of) pd as static library**
**Status:** open
**Group:** wishlist
**Labels:** dev libpd
**Created:** Thu Jun 05, 2014 12:55 PM UTC by IOhannes m zmölnig
**Last Updated:** Thu Jun 05, 2014 12:55 PM UTC
**Owner:** Miller Puckette
the attached patch makes the autotools-based build-system additionally create most part of the pd as a static library "libpd-core".
this static lib can then be used to e.g. build `libpd` without using the copy puredata that comes bundled with libpd itself. (thus avoiding the code-copy)
---
Sent from sourceforge.net because pd-dev(a)lists.iem.at is subscribed to https://sourceforge.net/p/pure-data/patches/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pure-data/admin/patches/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
recently, i received a bug-report for the "puredata" Debian-package,
that warned of conflicting declarations of the glist_scalar() function.
the problem seems to be, that glist_scalar() uses "int argc" for it's
A_GIMME argument in the declaration in g_canvas.c, but uses "t_int
argc" in the function definition in g_scalar.c.
now "t_int" is defined as a "pointer-sized integer", which is a "long
int" on amd64, thus incompatible with the 32bit "int".
it is often tempting to use "t_int" whenever possible, as it is the
Pd-native integer type.
unfortunately this can (and will) break binary compatibility in some
cases.
i think it should be *well documented* which types to use.
e.g. the only way to find out how to use A_GIMME is reading the source
code (where we have at least 4 occurences that use "t_int"
(glist_scalar(), curve_new(), plot_new() and drawnumber_new()) and a
lot more (>200) uses of "int".
also t_listmethod and t_anymethod in m_imp.h seem to suggest that
"int" is the correct type (though "m_imp.h" was historically
considered a "private" header, not meant for documentation).
i think it's necessary to fix all uses of "t_int argc" to "int argc".
additionally i think it would be good to:
- - clearly document the function-signature for (A_GIMME) callbacks (and
while doing so, move the various callback-typedefs from m_imp.h to m_pd.h)
- - split the generic "t_int" type into multiple names, that suggest
their usage.
afaict, the original use of "t_int" is for the dsp process function
(t_perfroutine) , though the name does not suggest anything like this.
probably we should move to a new (probably even more pointer-like) type
typedef t_perfarg void*;
and replace all other uses of t_int (e.g. the return value of
"atom_getint()" or the struct-member "t_resample.upsample") by other
types, e.g. "int",
for compatibility reasons, we might need to keep the two (or more)
types the same size, but they should be separated on a semantic level.
msdr
IOhannes
PS: it's pure coincidence that we had this recent conversation on
pd-list, where argc was declared "short".
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750168
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iQIcBAEBCAAGBQJTjEvdAAoJELZQGcR/ejb43zYQAItRxoL1PTtTVOGZsbP8ZPqs
prt/bGDQRF9LbyNGGAvLjlQEVIgNTaVf51m/pIoFngif3b9LuBRSPWjjpWirwQeC
Xu9wRMzNucuWmxCTAlxqUYFZn30Yl5aqw2KE7nDdo372lY8S130wbhopwRT/i/jX
fEQpQqbo3Ub6kRRbHmKbCXAZhbS8APgJiJxZPRYHetkDzqnksHDEi0PrQi+R/5Ko
UkoefV7QsTl9uZAEw22HUlmShdSaigh7EMqezWHfXomqu2qU/T6/ho8fF8y65V45
PeE8aXqEOvFW4tKsdQ4i8cIBu+SNxEWNMtTW3ETBxUsBQnmJCvS7/GS4E4anCWzf
eA9FmzB7OEyn3LGaZJaON/hAzuL67ICdQJXQvmYkSmr/M1HA5yUj98HTtidLQo/6
LvxvJa0n+EzK4Xrnr7Janna2Un8ySa94L36DV9DpgXS+7NvwUEAfVIBMMfrm8x+i
YS7AKjQABN0FukpdeXFTIr4D+eSr0C2Xsk6CcUoAlFa79i1MY2p0EkS7Lj6pXBuv
Oo7UMR1ZDCubE+I1xTvGqs0+SkHwuq/ohAFDcA9ZskD5jtNfM1DwAEEOHMvyJiHT
8Q1xJ646ZrSGM12RceRJUEzv2ROexYHXAkm/bfWo883DjGnMlQgaHUQC3/MEdk3p
GFrPBNIK5wgf7wned5N7
=whxF
-----END PGP SIGNATURE-----
---
** [bugs:#1145] inconsitent type of argc in A_GIMME-callback**
**Status:** open
**Group:** v0.45
**Labels:** API devel
**Created:** Mon Jun 02, 2014 10:11 AM UTC by IOhannes m zmölnig
**Last Updated:** Mon Jun 02, 2014 10:11 AM UTC
**Owner:** Miller Puckette
recently, i received a bug-report for the "puredata" Debian-package,
that warned of conflicting declarations of the glist_scalar() function.
the problem seems to be, that glist_scalar() uses "int argc" for it's
A_GIMME argument in the declaration in g_canvas.c, but uses "t_int
argc" in the function definition in g_scalar.c.
now "t_int" is defined as a "pointer-sized integer", which is a "long
int" on amd64, thus incompatible with the 32bit "int".
it is often tempting to use "t_int" whenever possible, as it is the
Pd-native integer type.
unfortunately this can (and will) break binary compatibility in some
cases.
i think it should be *well documented* which types to use.
e.g. the only way to find out how to use A_GIMME is reading the source
code (where we have at least 4 occurences that use "t_int"
(glist_scalar(), curve_new(), plot_new() and drawnumber_new()) and a
lot more (>200) uses of "int".
also t_listmethod and t_anymethod in m_imp.h seem to suggest that
"int" is the correct type (though "m_imp.h" was historically
considered a "private" header, not meant for documentation).
i think it's necessary to fix all uses of "t_int argc" to "int argc".
additionally i think it would be good to:
- clearly document the function-signature for (A_GIMME) callbacks (and
while doing so, move the various callback-typedefs from m_imp.h to m_pd.h)
- split the generic "t_int" type into multiple names, that suggest
their usage.
afaict, the original use of "t_int" is for the dsp process function
(t_perfroutine) , though the name does not suggest anything like this.
probably we should move to a new (probably even more pointer-like) type
typedef t_perfarg void*;
and replace all other uses of t_int (e.g. the return value of
"atom_getint()" or the struct-member "t_resample.upsample") by other
types, e.g. "int",
for compatibility reasons, we might need to keep the two (or more)
types the same size, but they should be separated on a semantic level.
i'm attaching a patch that changes the use of `t_int` to `int` in A_GIMME callbacks.
---
Sent from sourceforge.net because pd-dev(a)lists.iem.at is subscribed to https://sourceforge.net/p/pure-data/bugs/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pure-data/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
Sure. I guess I don't know what I'm saying :D other than the question: what do we reasonably need? Does the current solution work or is the next step required?
On May 22, 2014, at 5:03 PM, pd-dev-request(a)lists.iem.at wrote:
> To me, I think the ultimate use case is to be able to fire up two versions of pd in the same processing chain (take vst's in a DAW for example), load each one with identical patches, and have them controlled separately. This would be a fantastic boost for the ability to extend what we can already do with Pd as an audio processing engine, separated from its native GUI. Locking may be necessary in places, but then that is extremely fast these days.
>
> Of course, this all leads to the pdinstance being able to manage the symbol table along with Miller's recent changes, but what are the difficulties in achieving this? It seems like Miller tried and it was more difficult than what we are imagining.
>
> cheers,
> Rich
--------
Dan Wilcox
@danomatika
danomatika.comrobotcowboy.com
Howdy Miller,
This looks great and is definitely something we've been excited about.
On May 11, 2014, at 6:00 AM, pd-dev-request(a)iem.at wrote:
> To Pd developers...
>
> I've adapted Pd to nternally use a "pdinstance" structure to allow
> multiple schedulers (including DSP chains) to run in one address space.
> With slight modification (see below) libpd can use this to run separate
> patches asynchronously.
>
> I tried to "instance-ize" all Pd symbols to keep them private but ran into
> seemingly insoluble problems, so am leaving all symbols global for now.
> (So patches used in pdlib, if they want to be usable in a multiple-instance
> scenaro, should protect all send/receive/table/delay/etc named objects with
> a $[0-9] somewhere.
Judging from quickly scanning the test code, the main difference on our end would be switching context between instances?
I was brainstorming a future api for multiple instances along the lines of simply adding a instance index or pointer version of each of the existing libpd api calls, such as:
int libpd_bang(const char *destination); // current function
int libpd_bang(t_pdinstance* instance, const char *destination); // additional instance version (probably better to use a pointer, etc)
We could then call pd_setinstance, pdinstance_new etc internally ...
t_pdinstance* libpd_init(); // default, single use case; sets internal default instance pointer and returns it
int libpd_init(t_pdinstance* instance); // creates a new instance, returns 0 on success
... but in the end perhaps simply adding the new functions directly is simpler:
t_pdinstance* libpd_init(); // returns default internal instance or null on failure
t_pdinstance* libpd_new_instance();
void libpd_set_instance(t_pdinstance* instance);
> I didn't look hard, but I thnk pdlib now will need a way to send $ arguments
> to patches via libpd_openfile() somehow. Also, libpd_init_audio() will want to
> make number of channels per-instance, etc. I've put some relevant comments
> in the test program I'll include below (and sorry for the length of this
> mail!)
Ok cool. We've got something to go on, great!
--------
Dan Wilcox
@danomatika
danomatika.comrobotcowboy.com