-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 2012-12-10 22:17, Hans-Christoph Steiner wrote:
>
> I'm CC'ing pd-dev since this is good to have in the public and on
> the record.
yes, definitely. thanks.
i'm moving it from pd-list to pd-ev though.
>
> I think the problem was that Fink's 'autoconf' was installed but
> not Fink's 'automake-1.10'. So we need to decide to either go
> full native or full Fink for the autotools. The minimum build env
> I support is 10.5, so that means:
i think this explains the problem and suggests the correct solution.
> If things need newer versions than that, then I say we just use
> all of the Fink packages. Then we could have:
>
personally i think it is a good idea to have the build farm provide
both "native" and "fink" environments.
for PdX, fink is probably the way to go, but for single externals it
could be interesting to build it on the native platform as well.
fgmasdr
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlDG8EcACgkQkX2Xpv6ydvQlhQCgo02KBadGwAwX0GdUu4e8hHOM
Zv8AoNiVmkveL2MRjyRj4+b/WqvnDyya
=xCsH
-----END PGP SIGNATURE-----
Bugs item #3594832, was opened at 2012-12-11 09:35
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3594832&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: windows will not close
Initial Comment:
windows will not close
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3594832&group_…
Patches item #3594735, was opened at 2012-12-10 19:14
Message generated for change (Tracker Item Submitted) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3594735&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: bugfix
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: Miller Puckette (millerpuckette)
Summary: Win32: unicode support for files with public API for externs
Initial Comment:
Right now, Pd on Windows does really badly if there are any non-ASCII characters in the path or filename. It makes it freeze for a while, and sometimes crashes it. These patches fix that.
Pd and Tcl/Tk is UTF-8 internally, and UNIXes all use UTF-8 for filenames
and paths. Windows uses UCS-2 everywhere, which is a 16-bit format. The
only place this affects Pd is reading and writing filenames, and printing
to the console. The POSIX-style functions open() and fopen() exist on
Windows, but only work for ASCII filenames. To support Unicode filenames,
we have to convert the UTF-8 to UCS-2, then use Win32-specific functions.
Since any external that opens files will also be affected the same
way, this patch provides a public API: sys_open()/sys_close(), and
sys_fopen()/sys_fclose(). For non-Win32 platforms, they are just
names that point to the normal POSIX versions. On Win32, they are
special functions to handle UTF-8 to UCS-2 conversion.
I have built and run this on Windows XP, Mac OS X 10.6, and Debian/squeeze amd64. These patches are also included in Pd-extended 0.43.4.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3594735&group_…
Bugs item #3594476, was opened at 2012-12-10 05:48
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3594476&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: v0.43
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: gui not updating properly
Initial Comment:
I'm using 0.43.2 on debian wheezy, with two rme 9636 soundcards via jack.
When I'm using the attached patch, a lot of gui elements stop updating visually.
I can still change the value of, for example, numberboxes and radio's, but they don't show their new values on screen.
Same behaviour when their values are changed by other atoms.
Otherwise the gui is fully functional, and also print works as expected.
You can reach me for further questions via bart_ReplaceWithAt_magnetophon.nl
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3594476&group_…
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 2012-07-03 23:11, Miller Puckette wrote:
> Hi all,
>
> Pd version 0.43-3 is available on
> http://crca.ucsd.edu/~msp/software.htm
cool.
>
> I'm ready to start hacking on 0.44. The most urgent thing seems to
> be for me to go back and work on the audio system (and perhaps
> tweak MIDI a bit more too).
i have a project lying on my hardisk for >1 year (iirc, shortly before
the 0.32.0 release), that is related to that: separating the audio
system(s) from Pd-core.
background:
currently Pd supports a number of audio-backends.
while these backends are mainly separated into several source files
(e.g. s_audio_alsa.c for ALSA), there is a lot of theoretically
backend-agnostic code (s_audio, s_midi, s_main) cluttered with "#ifdef
USEAPI_ALSA" and the like.
this makes the current code badly readable and thus maintainable, it
also makes it hard to add new audio systems as backends (and the more
you add, the more complicated the codebase gets).
more background:
currently all audio backends are linked to the main "Pd" binary.
if your version of Pd is compiled for alsa, jack, OSS and portaudio
(the default on debian), you have quite a number of dependencies. (as
maintainer of the "puredata" debian package i prefer to keep necessary
dependencies at a minimum).
furthermore, Pd supports outdated/deprecated backends like OSS (both
audio and midi).
in practice i haven't used OSS-midi for a number of years (and i doubt
whether it is actually still supported by the mainline kernels), and i
used OSS-audio only seldomly in very specific setups.
from this i follow, that the majority of people have to fight their
way through a lot of dead options that are more confusing than
helpful, and which should probably be removed in most cases.
suggestion:
so what i ended up doing, was separate the audio-backends from the
pd-core code a bit more, in a similar way to how Pd's object
registration works.
the means that people could write new audio-backends and load them
on-demand, just like "externals".
it also means that Pd's non-audiosystem codebase has only a minimum of
"#ifdef USEAPI_ALSA" (there's only one, when it comes to loading the
"internal" audio-system at startup).
all this also applies to MIDI.
if there's interest, i could cleanup the patches (and make them work
again with 0.43.3) and submit them for review.
if there's confusion, i could try to try again and explain what i want.
fgmasdr
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk/z9ewACgkQkX2Xpv6ydvRvMwCgv2NPmX2Hx9wZSubBHA3mKpRd
IrkAoJbWuNJF1Gu2X7Vg1T+f1NHUdBbi
=fPn6
-----END PGP SIGNATURE-----
Patches item #3591846, was opened at 2012-12-02 08:56
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3591846&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: bugfix
>Status: Closed
>Resolution: Accepted
Priority: 9
Private: No
Submitted By: IOhannes m zmölnig (zmoelnig)
Assigned to: Miller Puckette (millerpuckette)
Summary: portaudio fixes
Initial Comment:
this patches fixes the current portaudio implementation.
since it is too big to be added to the patch-tracker (i imported portaudio-20121129), you can download it from http://iem.at/~zmoelnig/0001-updated-to-portaudio-20121129-snapshot.patch.b…
----------------------------------------------------------------------
>Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-12-08 07:54
Message:
a different patchset (based on the 20121031 pa-snapshot has made it into
Pd-0.44)
----------------------------------------------------------------------
Comment By: Miller Puckette (millerpuckette)
Date: 2012-12-03 10:46
Message:
... in case this makes it easier, here's the snapshot I last used:
http://crca.ucsd.edu/~msp/tmp/pa_snapshot_20121031.tgz
if you try diff -r --brief between this and Pd's copy in src/portaudoi you
can see how I pruned the
portaudio tree to include only stuff relevant to Pd. Oddly, I had to
supply one extra file though,
pd/portaudio/src/os/mac_osx/pa_mac_hostapis.c
----------------------------------------------------------------------
Comment By: Miller Puckette (millerpuckette)
Date: 2012-12-03 10:05
Message:
I tried this and got:
[msp@fuzz pd]$ git apply
~/bis/var/download/0001-updated-to-portaudio-20121129-snapshot.patch
/home/msp/bis/var/download/0001-updated-to-portaudio-20121129-snapshot.patch:287:
trailing whitespace.
/home/msp/bis/var/download/0001-updated-to-portaudio-20121129-snapshot.patch:300:
trailing whitespace.
/home/msp/bis/var/download/0001-updated-to-portaudio-20121129-snapshot.patch:336:
trailing whitespace.
* The text above constitutes the entire PortAudio license; however,
/home/msp/bis/var/download/0001-updated-to-portaudio-20121129-snapshot.patch:341:
trailing whitespace.
* they can be incorporated into the canonical version. It is also
/home/msp/bis/var/download/0001-updated-to-portaudio-20121129-snapshot.patch:342:
trailing whitespace.
* requested that these non-binding requests be included along with the
warning: squelched 32389 whitespace errors
warning: 32394 lines add whitespace errors.
... is there any way you can supply a patch that doens't add trailing white
space to 1/2 ot the Pd
source?
thanks
M
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-12-02 09:07
Message:
raising priority, since the current state of affairs breaks all builds from
current git.
what i did:
- after the import of the portaudio-20121101 snapshot, some files where
missing to smoothly integrate with Pd's autotools system.
- so I re-imported portaudio with the missing files (and used the 20121126
snapshot, since that was the one i found on the portaudio website)
- I tried to keep the import to a minimum (but imported all files an
ordinary make would want to run a compilation)
- i added the new portaudio build-system to pd/configure.ac (so pa's
configure will get called automatically by Pd's configure)
- i also adjusted the link-path of libportaudio in pd/src/Makefile.am to
it's new location
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3591846&group_…
Bugs item #3593741, was opened at 2012-12-07 09:59
Message generated for change (Tracker Item Submitted) made by danielhjames
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3593741&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pd-extended
Group: v0.43
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Daniel James (danielhjames)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: 8 channel Ogg Vorbis file does not play at correct speed
Initial Comment:
Using 0.43.4-extended-20121114 on Ubuntu Lucid, I can play a two channel Ogg Vorbis file or an eight channel WAV file but I cannot play an eight channel Ogg Vorbis file (made with Audacity, plays correctly in VLC) without the result sounding very slowed down. Please see attached screenshot of a demo patch. Please et me know if you would like sample audio files.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3593741&group_…
Hey Miller,
I see that you are using MSVC via Wine on GNU/Linux. I don't know how well supported that arrangement is, for a widely supported version of that arrangement, you should try running the MinGW builds on GNU/Linux. The makefile.mingw should work fine for that just set compiler (i.e. make CC=/path/to/mingw-gcc). Here's lots of docs for doing this on Fedora:
https://fedoraproject.org/wiki/MinGW
Most distros include a mingw-gcc cross-compiler, so they just need to 'yum install', 'apt-get install', etc.
.hc
Patches item #3578746, was opened at 2012-10-20 10:47
Message generated for change (Comment added) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3578746&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Miller Puckette (millerpuckette)
Summary: [bugfix]: non-2^n-BS bug
Initial Comment:
I'm really not a 'spammer'! ...nor a hypochondriac...
I've tested several versions of pd (0.42.5 - 0.43.3 (ext/van)). None of them is working with non-2^n-BSes!
On the mailing-list ( http://www.mail-archive.com/pd-dev@iem.at/msg11344.html ), Claude Heiland-Allen states that it is already implemented..
(Thanks Claude) But I can't confirm that. I've tried the patch he posted there, - without success: The blocksize is always rounded to the next bigger power of 2, it seems!
I don't know what he's on, but I'm on windows. Maybe that makes the difference..
(Is this a hardware- or Os-dependent feature..??)
Please take a look at the attached pd-patch. It's my attempt to work out the problem..
If someone could give me a resonable answer, I promise I'll never come back again ;) ...for this issue...
PS: It feels a little annoying if one does not get a real response or not a response at all! (Eg. look at the feature requests. The last one on the 1st page is like 2 years old, so you can't say there are too many to respond to each one..).
This especially is true if the response is longer than the acual answer like "Yes", "No" or "I don't know". That would have been a big help for me already. Although it's not making the bug disappear automatically...
Anything like if it is a useful/good idea is something I'd like to know, when posting something, for exapmle..
But no, I won't be scared away so easily..
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2012-12-05 01:17
Message:
Enjoyed looking through this, very good stuff, regards .
<a href="http://social.webinova.us/jcow/blogs/viewstory/21641" title="Most
Current In Addition To Modern Maxi Garments On The Net">Most Current In
Addition To Modern Maxi Garments On The Net</a>
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-10-30 00:50
Message:
feel free to report oddities as bugs - and please report each oddity as a
separate bug (in the bug-tracker rather than follow-ups on this ticket)
als make sure you report issues and don't ask questions like "how does this
work?" :-)
(and if you want to discuss the tracker/forum/mailinglist/IRC thing, please
join the mailinglist and/or the IRC...!)
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2012-10-29 23:13
Message:
...oh now it's here...
Just in case you're working on BS-things anyways I only wanted to mention
that I have some more BS-related oddities. If you are interested, I can do
a search and gather them.
If you are talking about the hurleur-forum, I always thought that was not
the right place for the devs?!? ..I haven't been there for a while ...since
I have no problems with the installation... ;)
I never wanted it to be only a question.. and it finally turned out to be a
real bug. ..after the third try to convince you... ...I do what I can to
help.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-10-25 07:43
Message:
@op: if you don't feel comfortable with the mailinglists, why not use
another support-channel (IRC, forum?)
the sf-trackers are here to track bugs and issues, not questions.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-10-25 07:38
Message:
indeed i can confirm the bug (as discussed on the mailinglist).
i'll attach a (simplistic?) fix that appears to make it work with current
git (and this time i tried hard to avoid introducing trailing whitespaces)
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2012-10-24 06:38
Message:
I didn't know about that. I find the lists to be a little confusing.. There
are so many, with all the archives. And sometimes some posts (from sf) only
occur at the archive if I'm not mistaken..???
But I'll take a closer look...
Anyways, did you (or someone else) take a look at the file??
Oh and just let me take this chance to thank you very very much for this
brilliant piece of software. This is far more than programming. If it
wasn't that good, it wouldn't have take me that much time... ..I mean I
wouldn't have spent it...
----------------------------------------------------------------------
Comment By: Miller Puckette (millerpuckette)
Date: 2012-10-20 21:38
Message:
Sorry - SF is a pain for me - can you follow up on the mailing list? That
way more people will
be able to find the long thread that will doubtless ensue.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3578746&group_…
Patches item #2947822, was opened at 2010-02-08 05:12
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=2947822&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: None
Status: Open
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Matteo Sisti Sette (sistisette)
Assigned to: Miller Puckette (millerpuckette)
Summary: space character in gui labels causes disaster
Initial Comment:
Steps to reproduce:
1 - Open the attached patch
Note the size of the radio and toggle. Note also they have "send" symbols set to "xxx" and "yyy" respectively
2 - Click on the big bang at the top
This composes a symbol containing space characters and sends it as a label to both the radio and the toggle.
This seems to work: the label is actually set with spaces, and the radio and toggle still work.
However, if you right-click on any of them and try to select "properties", the properties dialog won't open
3 - Now save the patch and close it
4 - Open the patch again. The radio and toggle properties have been completely "reset": their size have been reset to default, and also the "number" property of the radio. They have lost their "send" symbol too: you can see the outlet and if you use them, the "r" objects won't receive anything.
However, if you open the properties dialog of the radio or toggle, you'll see that the "send" property is still there (not the same can be said for the size and number); if you now do Apply or Ok, the send symbol will be restored.
So, spaces in the label of a gui object cause weirdnesses and potential disaster. Note that data is lost (the properties of the gui objects) if the patch is saved after assigning such a label, and i is lost silently with no error message at any moment.
There are ather "forbidden" characters ithat don't behave properly n labels, such as the open square bracket "[" (as reported in another bug report). However the space character is more disatrous as it causes data loss.
Object should either accept ALL characters for a label, or properly detect and refuse forbidden characters, which should be documented, avoiding unexpected consequences.
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-12-04 11:31
Message:
Patch #0001 should be applied regardless. Its a simple fix that also
address having characters like " [ ] in labels.
As for patch #0002 , the iemguis also replace spaces with _ when you enter
the name in the Properies panel. Symbols can have spaces, and you can set
the label with a [label symbol( message, so as IOhannes pointed out, the
missing piece of the puzzle is saving properly. Since patch #0002 makes Pd
write out the file format that is already supported, I think it would be
good to include it.
Then strnescape() will also have to change when we implement proper
escaping support throughout Pd. Unless you have plans to implement that in
0.44, I think its definitely worth including incremental solutions like
patch #0002
----------------------------------------------------------------------
Comment By: Miller Puckette (millerpuckette)
Date: 2012-12-03 19:27
Message:
Note the much simpler way the "number box" finesses this problem. I'm
scared of adding
code to m_binbuf.c to escape spaces (what will happen when we later allow
backslashes
into the mix?). But without the binbuf patch the fix to the IEM guis
doesn't work - so I'm
tempted for now just to do as in the number box - it's not incompatible to
"do it right" at
some ater date when we can thonk the whole thing through (it's all over the
Pd code and all
needs to be figured out together).
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-11-13 16:45
Message:
added another patch (0002_*) that implements escaping spaces and tabs when
saving the files to disk.
i guess both patches should be applied for full fun.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-11-13 15:36
Message:
the bug.pd file does not correctly show the labels with blanks after
reloading but it doesn't throw any warnings)
however, the bugfix-patch doesn't work for me.
nevertheless the problem is known and is not in the pd->gui communication,
but rather in the way the label is stored on disk (and then interpreted on
reload):
afaict, blanks (and other special chars) really must be escaped with
backslash (e.g. "A\ A\ A") when saved to disk
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-11-13 12:52
Message:
the values were not quoted, so just quoting them with {} fixes it. The
patch is attached.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=2947822&group_…