settable box widths.
hi there, please, how can I use this new feature? I didn't get it.
cheers
2013/8/23 Miller Puckette m...@ucsd.edu
Hi all,
Pd version 0.45-0 is available on http://crca.ucsd.edu/~msp/software.htm
or via git from sourceforge:
git clone git://git.code.sf.net/p
Cool... I can take the message out :)
M
On Thu, Aug 22, 2013 at 08:52:28PM +0200, Max wrote:
i can confirm it seems to work fine in 0.45-0 test3 on OS X
midirealtimein: works under MSW only
Am 14.12.2008 um 15:01 schrieb hard off hard@gmail.com:
was just messing round with
Here's another possible approach... to get the dialogs etc to look OK you
can comment out the line tk scaling 1 in tcl/pd-gui.tcl (a long confused
thread on this: http://lists.puredata.info/pipermail/pd-dev/2013-06/019517.html)
and then to get the actual patch contents to look OK again, try to
Have at it... test 3 is now up on the usual...
http://crca.ucsd.edu/~msp/software.htm
or
git://git.code.sf.net/p/pure-data/pure-data
cd pure-data
git checkout -b 0.45 0.45-0test3
Hopefully this fixes all the bugs that have shown up on pd-list so far.
cheers
Miller
Hi all -
Thanks for the helpful reports about test 1 - I've now put out test 2 that
(I hope) fixes all the problems that popped up today except that I don't
know where the ASIO problems are coming from yet... I'll keep fooling with
that.
It's on:
http://crca.ucsd.edu/~msp/software.htm
or:
git
, IOhannes m zmölnig wrote:
On 08/19/13 07:43, Miller Puckette wrote:
OK... I left these ones out:
pd2puredata.patch
usrlibpd_path.patch
fixmanpage.patch
helpbrowser_puredata-doc.patch
since I think they're debian-specific; took the other 11. Thanks - they
look
helpful
Miller
On Mon, Aug 19, 2013 at 12:13:35PM +0200, martin brinkmann wrote:
On 08/19/2013 08:11 AM, Miller Puckette wrote:
Hi all -
I've now put out test 2
there seems to be a new behaviour concerning tabread4~ and upsampling:
(compared to 044, i have not checked the 1st 045 version
to compare with the standard pd, the best result I achieved is
1.45/2.9ms with -noaudio.
Nicola
Il 27/11/2012 18:50, Miller Puckette ha scritto:
I believe if you edit s_midi.c and change:
if (midi_outqueue[midi_outtail].q_time = midirealtime)
to
if (1
Miller,
Thanks for the new features!
On Sun, Aug 18, 2013 at 3:51 AM, Miller Puckette m...@ucsd.edu wrote:
Hi all,
Pd 0.45-0test1 is now up on http://crca.ucsd.edu/~msp/software.htm
or via git from sourceforge:
git clone git://
pure-data.git.sourceforge.net/gitroot/pure-data/pure
OK... attempted fix in place. I don't understand the automake system so this
might take an iteration or 2.
thanks
M
On Sun, Aug 18, 2013 at 11:58:33AM +0200, Jack wrote:
Le 18/08/2013 03:51, Miller Puckette a écrit :
Hi all,
Pd 0.45-0test1 is now up on http://crca.ucsd.edu/~msp
right you are... fixed.
chanks
M
On Sun, Aug 18, 2013 at 12:08:36PM +0200, Jack wrote:
Le 18/08/2013 03:51, Miller Puckette a écrit :
Hi all,
Pd 0.45-0test1 is now up on http://crca.ucsd.edu/~msp/software.htm
or via git from sourceforge:
git clone git://pure
approach for glists in general some time ago?
I compiled Pd 0.45-0test1 on Xubuntu 10.4. I'm sorry to report the
following: if the help patch for [list] is opened, Pd exits with
'Segmentation fault (core dumped)'.
Katja
On Sun, Aug 18, 2013 at 3:51 AM, Miller Puckette m...@ucsd.edu
Can you remind me what OS and audio hardware you're on? (I tested this
on Windows XP / ASIO4ALL but clearly I need to figure out how to test other
configurations somehow.)
cheers
Miller
On Sun, Aug 18, 2013 at 03:25:09PM +0200, Colet Patrice wrote:
Le 18/08/2013 03:51, Miller Puckette a écrit
Yep - I need to update pointer's help file to mention text items in
scalars - meanwhile the magic is described in the [text] help file. But
there's a bug report out already (don't hit the '0' message :)
I'm planning to make a way for the 'pointer' object to delete individual
scalars but can't
Puckette a écrit :
Can you remind me what OS and audio hardware you're on? (I tested this
on Windows XP / ASIO4ALL but clearly I need to figure out how to test other
configurations somehow.)
cheers
Miller
On Sun, Aug 18, 2013 at 03:25:09PM +0200, Colet Patrice wrote:
Le 18/08/2013 03:51, Miller
, Miller Puckette m...@ucsd.edu wrote:
Hi all,
Pd 0.45-0test1 is now up on http://crca.ucsd.edu/~msp/software.htm
or via git from sourceforge:
git clone git://
pure-data.git.sourceforge.net/gitroot/pure-data/pure-data
git checkout 0.45-0test
It seems to me
OK .. this and Jaime's other report (x labels not updating when resize table
using [array size] should now be fixed in git (to appear in 'test 2 later -
first I want to look at ASIO some more)
cheers
Miller
On Sun, Aug 18, 2013 at 08:47:34PM +0100, João Pais wrote:
When testing the text and
I'll check - if they look safe I'l lthrow them in.
cheers
M
On Mon, Aug 19, 2013 at 04:45:48AM +0200, IOhannes m zmölnig wrote:
great news.
i'm currently more or less offline, so i couldn't really have a closer
look yet.
in the meantime, would it be possible to do a quick check on the
OK... I left these ones out:
pd2puredata.patch
usrlibpd_path.patch
fixmanpage.patch
helpbrowser_puredata-doc.patch
since I think they're debian-specific; took the other 11. Thanks - they look
helpful!
On Sun, Aug 18, 2013 at 08:21:21PM -0700, Miller Puckette wrote:
I'll check - if they look
Hi all,
Pd 0.45-0test1 is now up on http://crca.ucsd.edu/~msp/software.htm
or via git from sourceforge:
git clone git://pure-data.git.sourceforge.net/gitroot/pure-data/pure-data
git checkout 0.45-0test1
Some new features:
binary netsend/netreceive (so you should no longer need an extern
I believe it should not happen ($1-loop would expand to different symbols
depending on $1).
cheers
M
On Sat, Aug 10, 2013 at 11:23:19AM -0400, Jonathan Wilkes wrote:
On 08/10/2013 10:37 AM, Jonathan Wilkes wrote:
On 08/09/2013 08:01 PM, Miller Puckette wrote:
Well, if ia user really wants 32K
Hi Patrice -
I actually don't have any working ASIO devices which makes it hard for me
to figure out what's wrong here. I'll make another attemot to get something
installed in the next week or so. Meanwhile, am I reading this right that
you get different results depending on whether you put the
Hi Miller,
Just very generally BTW:
Do you mean binary compatibility or patch compatibility?
Either way, what are your thoughts about the possibility of a future Pd-1.0
which would break (some kind of) compatibility for the sake of
revolutionary progress?
András
I'm unwilling to
:27, Miller Puckette wrote:
Here's a guess - I think each copy of the abstraction binds itself to
a symbol, pd-name. Binding is fast bt unbinding is linear-time in the
number of things bound to the symbol... ouch.
Yes, I think that's it:
git master from yesterday
Pd-0.45.0 (test
Or... just limit the number of canvases that can bind themselves to a single
symbol to a reasonable number (5 or so, settable by flag for back-compatibility
if anyone cares).
cheers
M
On Fri, Aug 09, 2013 at 07:51:30PM +0100, Claude Heiland-Allen wrote:
On 09/08/13 19:42, Miller Puckette wrote
thinking)
Pd should make it easy to defeat that useless behavior.
cheers
M
On Fri, Aug 09, 2013 at 07:11:02PM -0400, Jonathan Wilkes wrote:
On 08/09/2013 04:31 PM, Miller Puckette wrote:
Or... just limit the number of canvases that can bind themselves to a single
symbol to a reasonable number
Here's a guess - I think each copy of the abstraction binds itself to
a symbol, pd-name. Binding is fast bt unbinding is linear-time in the
number of things bound to the symbol... ouch.
There's a good reason to bind toplevels and named sub-patches to ther names,
but I think there's little reason
version of ipoke~, by Katja), but it's only for
overdubbing)
Thanks again.
El 07/08/13 04:57, Roman Haefeli escribió:
On Wed, 2013-08-07 at 08:40 +0200, IOhannes m zmölnig wrote:
On 08/07/13 03:15, Miller Puckette wrote:
Hmmm... I was umnder the impression that, except for the overhead
, Miller Puckette escribió:
Here's an idea ... perhaps your patch is generating hundreds of thousands
of symbols to instantiate all the abstractions, and this sould be making
gensym() run slowly. To test this possibility easily you could change
#define HASHSIZE 1024
to
#define HASHSIZE 65536
Hmmm... I was umnder the impression that, except for the overhead of block~
and switch~ objects, there would be no difference in DSP execution time
between a patch having lots of subpatches and one with the same amount of
computation all thrown in one window. I haven't made any measurements but
I tried this with four versions of a subpatch, one with nothing (just an
inlet connected through to an outlet), one with a float, one with hslider, and
one with a number box (not number2, just control-3 number). Subtracting
out the control case, I sent 100 random numbers through and asked the
What I do (in effect):
Get an existing Pd application and remove all the Pd sources
(Contents/Resources/src, bin, doc, tcl, portaudio, portmidi, extra, *.txt)
then un-tar a source tarball into Contrnts/Resources, cd to src, and
make -f makefile.mac
(Actually, of course, I do this from a script.
had it all working.
cheers
M
On Sat, Jul 06, 2013 at 06:08:13PM -0400, Jonathan Wilkes wrote:
On 07/06/2013 05:22 PM, Miller Puckette wrote:
What I do (in effect):
Get an existing Pd application
As in download one of your prebuilt mac binaries?
-Jonathan
and remove all the Pd sources
that's the loop~ object in extra.
cheers
Miller
On Thu, Jul 04, 2013 at 09:20:27PM +0200, Orm Finnendahl wrote:
Hi List,
sorry if I'm missing the obvious: I'd like to implement a phasor~,
which only allows its frequency to be changed on wraparound. Using a
samphold~ for that purpose
If it's just local, the list object will do it (floats and symbols are
just one-element lists).
If you want something that (like 'value') can be accessed by name or
pointer elsewhere in the patch, you might want the text object (in git
repo, upcoming for version 0.45). If you're insteested in
It might be fixed. I use make -f makefile.gnu from pd/src to avoice
all the automake horror, and so had allowed the automake to get out of sync
witht he source - Iohannes patched that so things migth be back to normal
with automake too by now.
cheers
M
On Thu, Jul 04, 2013 at 10:08:36PM +0200,
Aha... I never 'make install' myself - I'd better go look at that.
Anyhow I think it shoud have been 'make -f makefile.gnu install' instead...
cheers
M
On Thu, Jul 04, 2013 at 10:56:58PM +0200, yvan volochine wrote:
On 04/07/13 22:54, Miller Puckette wrote:
Relly - you can make a [text] object
OK.. I made an attempt to fix the problem a diffferent (perhaps smarter)
way... I made a change that migth make pd-watchdog quit more reliably when
Pd exits. I believe Pd itself wil still go into zombie state waiting for
its 'child' jackd to exit - and I think this is a problem in jack - but
I find configure scripts too complicated for human understanding, and so
I just use the hand-edited makefile: make -f makefile.mac, invoked from
the /src directory.
cheers
Miller
On Wed, Jun 26, 2013 at 02:47:58PM -0700, Jonathan Wilkes wrote:
Hi,
Any clues about this ./configure error:
Thanks... I'm toying with a middle solution, which would be simply to open
jack with the JackNoStartServer option (one of JackOpenOptions).
I think this is a good idea anyway as the user might want to specify
jack options and it seems wrong to have Pd get involved in that.
cheers
Miller
On Mon,
jack_client_open())
the new API allows more flexibility (e.g. the jackd need not run before the
application starts - if it is missing, it will be automatically launched)
TODO: jack is actually a callback-based API...
Signed-off-by: Miller Puckette m...@ucsd.edu
Is it possible
This may be related: after upgrading to Fedora core 17
(linux 3.6.3-1.fc17.x86_64) I found that, after running a patch for hours or
days, just shutting DSP off sometimes freezes my machine for somewhere between
1 and about 20 seconds (I think). I had never suspended or hibernated the
machine. I
it looks as if
Apple is the new Microsoft.
cheers
Miller
On Sun, Jun 16, 2013 at 12:39:31PM -0700, Jonathan Wilkes wrote:
From: Miller Puckette m...@ucsd.edu
To: Jonathan Wilkes jancs...@yahoo.com
Cc: pdlist pd-list@iem.at
Sent: Sunday, June 16, 2013
Looking at this now. I notice that _pipe in windows even allows you to
specify buffer size which linux and MacOS don't. It might be a major
advantage.
OTOH the major hassle is figuring out how to create and manage the sub-process
in Windows which has no wait() function. I fear people finding
I find the data structure deign extremely limited and have been thinking for
years about how to make it more powerful. I have a rather weak idea about
alowing deletion of individual items in lists that I'm planning to try out in
the run-up to the next release - not that that can help you right
That's what I did too :)
M
On Tue, May 28, 2013 at 05:22:06PM +0200, Roman Haefeli wrote:
On Die, 2013-05-28 at 13:40 +0200, João Pais wrote:
when you have a point defined by a variable, afaik it's always open to
user interaction. but, check the help for drawpolygon, the -x argument. I
and linking to ./pd
via bash. Works fine but isn't quite satisfactory somehow.
Anyway.
Hope we can get it going (I'm going to sit tight this time).
Regards,
Julian
On 23 May 2013 04:09, Miller Puckette m...@ucsd.edu wrote:
Looks like x_array.c and x_scalar.c were missing from
HI Dan -
I tried and got even less far than you apparently did, and gave up. It's too
bad - the UA 25 is the best USB-powered interface I've found so far. For the
Pi I now use small, cheap, recent-vintage ones like the Griffin iMic. (but
there are even cheaper ones :) If you have low-impedance
This is anecdotal, but Max Neupert told me yesterday that he installed
13.04 on a machine and found that he could no longer run skype. Apparently
the proprietary nvidia driver is to blame. So if you have nvidia graphics
(no matter what kind of CPU) beware!
Miller
On Tue, Apr 30, 2013 at
... so it sounds like there are at least 2 serious problems with the new
ubuntu affecting several applications - maybe a bit tighter quality control
is needed on their end :)
M
Here with (to use Intel graphics):
$ skype
it is OK.
But with (to use NVidia):
$ optirun skype
Skype crash.
I can't report about that but I have another compliant USB 1.1 interface,
Edrol UA25, which I've never been able to get to work with a pi. So I think
this is confirmation that that can indeed sometimes happen (if it were just
one of us perhaps it could have been a fluke).
cheers
M
On Sat, Apr
Hi All -
I've released 0.44-3 (source, and compiled for Windows and Mac) - I don't
have my Pi handy so will be updating the pi-compiled version later. The
main update is to fix the gain of the hip~ filter, which I still had wrong.
I was threatening to try also to fix largefile support for
I'm not sure but I believe that's because of rounding to the nearest pixel.
I don't believe Tcl/TK does any anti-aliasing, even if the underlying
graphical system does.
cheers
Miller
On Thu, Apr 18, 2013 at 12:30:55PM -0400, Billy Stiltner wrote:
anyone figured out why sometimes the graph
Hi Ricardo -
I never heard of that problem before... do you have a file
.../pd-/tcl/pd_connect.tcl ? That's what appears to be missing judging
from the messages you're getting.
cheers
Miller
On Fri, Apr 12, 2013 at 06:50:13PM +, Ricardo Cedeño wrote:
HI,
I've just tried to install pd
... and sorry, one last question - did you build it using make -f makefile.gnu
or with ./autogen.sh , etc?
thanks
M
On Fri, Apr 12, 2013 at 08:53:16PM +, Ricardo Cedeño wrote:
HI Miller,
I installed from source; i couldn't find PD packages in OpenSuSE
(http://software.opensuse.org) nor
Thanks... I don't understand that build system - perhaps someone who does
will comment :)
Miller
On Fri, Apr 12, 2013 at 09:26:53PM +, Ricardo Cedeño wrote:
I did it using ./autogen.sh, ./configure, and make install
cheers,
Ricardo Cedeño Montaña
Humboldt-Universität zu Berlin
At the moment, Pd is hardwired so that, if one stops DSP, the audio device
is closed for ASIO, MMIO, ALSA, CoreAudio, and OSS (not sure if I'm forgetting
one :) but is kept open if the current API is jack. THis is done so that
one doesn't lose jack connections when stopping and restarting DSP. I
can follow a branch on git and test for you if you wish.
Alternatively I recall there's debian package to host a 32 bits linux in
a 64 bits linux.
Thanks
Charles
Miller Puckette wrote:
OK... now I'm trying to fix the bug but I can't reproduce it. I made a
5 GB soundfile (wave format
you do something else besides just read the file from its beginning?
thanks
Miller
On Wed, Mar 20, 2013 at 06:20:59PM -0700, Miller Puckette wrote:
I believe not - every extern that used open_bia_path0 would have to be
fixed at the source level to use lseek64(), fstat64() in place of
lseek
-0700, Miller Puckette wrote:
OK... now I'm trying to fix the bug but I can't reproduce it. I made a
5 GB soundfile (wave format, 60 channels, 4-bit floats, 450 seconds long)
and opened and am reading it using readsf~. This is on a 64 bit linux
box.
Question for Charles Goyard: were you on a 32
and cope with it. Other people mostly won't notice.
My intuition is that if the LFS project was unable to provide a transparent
API in the first place, there's no reason we will be able to do anything
clean.
Just communicate enough about the breakage and enjoy :).
Miller Puckette wrote
+0100, IOhannes m zmölnig wrote:
On 03/20/2013 18:02, Miller Puckette wrote:
On further thought, I don't think it's even possible to change
open_via_path()
to use open64() and maintain even source compatibility for externs - if
one of them calls lseek or fstat we're sunk - and I don't see
fix the LFS
issue albeit at the expense of backwards/cross-platform compatibility? Also,
in Linux is open64 safe for both 32-bit and 64-bit OS variants?
-Original Message-
From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of
Miller Puckette
Sent: Wednesday
To answer Ico's question, the trouble I forsee is musician A gives
musician B a patch, containing compiled externs - and then musician B
runs it and gets a crash instead of music. Sub-optimal in my opinion :)
I now think that it should be OK to use open64() only in the file d_soundfile.c
and
about that?
thanks
Miller
On Sun, Mar 17, 2013 at 10:27:41AM +0100, IOhannes m zmölnig wrote:
On 03/16/2013 23:42, Miller Puckette wrote:
It's in the source - but Pd has to be compiled with '_LARGEFILE64_SOURCE'
defined for this to work. Through 0.43 the configure script I was using
It's in the source - but Pd has to be compiled with '_LARGEFILE64_SOURCE'
defined for this to work. Through 0.43 the configure script I was using
was checking for this somehow (too complicted for me to understand how).
Anyhow, this is a bug all right - thanks for reporting it!
... and can you
Hi all -
I don't think there's any way to implement [list append] that doesn't
require copying the list (tcl can do the append in place so doesn't have to
do that). So building a list of length n requires a compute time on the
order of n^2 - which gets to be problematic when n gets big.
Another
Hi all -
It's correct that if you're using non-synchronized udio devces, soner
or later some FIFO will over- or under-flow and you'll get dropped
audio samples. But lots of people seem happy to live with this - for
instance, I believe anyone using Jacktrip for multi-site performances is
doing
This is probably something I should fix... MIDI used to default to 'OSS'
on linux and now defaults to 'alsa' - but I'm not sure that's really
the appropriate default. In any event, since it now defaults to alsa we
clearly need a 'ossmidi' flag!
In the meantime, I put this in my .pdsetting o nthe
Alternatively, and perhaps a bit easier, you could grab my gpio object
from http://crca.ucsd.edu/~msp/syllabi/206.13w/index.htm - it's very
unfinished, but basically you can use the gpio command to set the pins
up, then crank up Pd and use a |gpio| object to read or write them - it
works through
... and oops, I see that the thread got split - on the other thread, the
solution from jack at rybn.org (using built-in Pd objects, notably
|textfile|) also works, and is certainly the easiest way to get started.
cheers
Miller
On Thu, Feb 14, 2013 at 10:27:02AM -0800, Miller Puckette wrote
Just a comment on Chris's last point:
Also, I don't get the obsession with the Pi. There are now lots and lots
of under $100 ARMv7 dual core (!) boards that run Linux and have way more
I/O options. Why not get something not totally out of date to begin with?
My personal reasons for being
I/O options. Why not get something not totally out of date to begin with?
My personal reasons for being attracted to the Pi are, 1, that it's vastly
better engineered and supported than other linux+ARM solutions I've seen;
and 2, although I'm not sure about this, it seems to dissipate
or ~/ or whatever.
how difficult to just get this version in the raspian repo so we can
all just do apt-get?
m
On Fri, Feb 1, 2013 at 1:40 AM, Miller Puckette m...@ucsd.edu wrote:
Hi all,
This is only of interest to Raspberry Pi users - I've fixed the denormal
problem Katja
Just to comment on why I ended up un-installing portaudio: I booted my
Pi with a clean new Raspbian distro, compiled Pd (after installing some
packages like git and alsa libs), ran it and found that pulseaudio was
running. So I exit Pd and likk pulseaudio via pulseaudio -kill. Then start
Pd and
Pulseaudio respawns itself, unless you've configured it not to. You
can disable it temporarily with the tool pasuspender.
The syntax would be:
pasuspender -- pd
Good to know - but even though I now theoretically know how to deal with this,
the whole thing gives me the creeps - what if some
Hi all,
This is only of interest to Raspberry Pi users - I've fixed the denormal
problem Katja reported and recompiled - you can get that and the new sources
from the usual sources:
http://crca.ucsd.edu/~msp/software.htm
or
git://pure-data.git.sourceforge.net/gitroot/pure-data/pure-data
I heard suggestions on the Pi sites (I forget exactly where) that the USB
2.0 implementation isn't compatible with a large variety of USB 2.0 devices
(including for instance the Griffin iMic). So I don't think the issue is
the load that USB 2.0 puts on the Pi, it's simply bugs. But I gather
... and to fill out the other possibility, it's also possible to install
the X windows app on Macintosh, get a terminal running inside X, then
ssh over to the pi (ssh -X address) - in which case the windows you open on
the pi should appear back on the Mac. This might be the lowest-tech way.
Since writnig that I think I found a good toolset and C api, called
WiringPi, on:
https://projects.drogon.net/raspberry-pi/wiringpi/
cheers
Miller
On Sat, Jan 26, 2013 at 10:29:17AM +0100, Charles Goyard wrote:
Hi,
python rpi-gpio uses /dev/mem and thus requires root privileges.
Miller
to pd
it depends on liblo and libbcm2835
it's very specific to my project but could help someone...
code is here : https://github.com/avilleret/pianophone
cheers
a
--
do it yourself
http://antoine.villeret.free.fr
2013/1/25 Charles Goyard c...@fsck.fr
Hi Miller,
Miller
versions worked nice on my (winxp + rme hammerfall) system. Things
went wrong somehow when I started to use 0.44-x.
Thanks for your help!
Hrvoje Radnic
http://soundcloud.com/sumovi-protiv-valova
From: Miller Puckette m...@ucsd.edu
This is mysterious to me - but it might help to put copies of all needed
abstractions in the directory that holds the patch you're asking Pd to
load. There mihgt be some chroot magic going on ni teh boot sequence that's
changing the meaning of paths somehow - that's a wild guess but at least if
pd vanilla release?
Thank you!
Hrvoje Radnic
http://soundcloud.com/sumovi-protiv-valova
From: Miller Puckette m...@ucsd.edu
To: Hrvoje Radnic hrvojerad...@yahoo.com
Cc: pd-list@iem.at pd-list@iem.at
Sent: Thursday, January 24, 2013 8:44 PM
Hrvoje Radnic
http://soundcloud.com/sumovi-protiv-valova
From: Miller Puckette m...@ucsd.edu
To: Hrvoje Radnic hrvojerad...@yahoo.com
Cc: pd-list@iem.at pd-list@iem.at
Sent: Thursday, January 24, 2013 9:37 PM
Subject: Re: [PD] pd vanilla 0.44-1 ASIO
Hi Charlot -
I think either I or a grad student (we'll see) will be writing a Pd extern
to do this efficiently -- for the moment it would be possible with a Python
script (using netsend/netreceive in Pd) but having an extern would be more
lightweight and probably more robust. I'm running an
That's an old, annoying bug in Vanilla...
cheers
Miller
On Thu, Jan 24, 2013 at 11:29:07PM -0500, Hans-Christoph Steiner wrote:
On 01/24/2013 10:38 PM, Seiichiro MATSUMURA wrote:
Hi Hans,
It's great to hear this!
Through checking this final builds, I notice 2 weird behaviors of it
audiodev and other device selecting options (MIDI for example) count the
devicesstarting at 1 (probably because the first OS I ran Pd on did it
that way but I don't even remember now). invoke pd -listdev' to see what
devices Pd actually thinks it can access and how it numbers them.
cheers
Miller
... and does pd-0.44-0 (or pd-0.43-2) still work? I'd be surprised if the
change from 0.44-0 to 0.44-1 broke that but who knows.
I happen to have a Hammerfall and a working PC so once I get them in the same
building I can try this too.
thanks
Miller
On Wed, Jan 23, 2013 at 03:03:41PM -0800,
Hi all,
I went looking in the logs and over a recent 28-day period I found only 441
distinct addresses downloading recent (0.43 or 0.44) versions of Pd - so
between 15 and 16 'unique' downloads per day. (The total number was over
6000 but I think unique addresses is a better measure.)
cheers
thanks - I'd better try this and find out what's going on :)
M
On Mon, Jan 21, 2013 at 11:54:29AM +0100, katja wrote:
Tried the 0.44.0 build from your website. It has the same issue with
subnormal values. My test patch is with [lop~]. If inf or nan is fed
into [lop~], these 'values' keep
That's great (and surprising) news... I wonder why you're getting a better
ride from teh E-MU box than I am from the iMic but it sounds as if I should
be digging up one like yours to try.
I think you can just invoke 'pd -sounddev 2' to select the USB device.
cheers
Miller
On Tue, Jan 22, 2013
Hi all...
I think it's possible to get flush-to-zero behavior on the Pi (ARMv6) by
calling gcc with --fast-math. At any rate what I found was that, if I
compiled without --fast-math, when numbers got small (e.g., when a
reverberator decays down past 10^-38 or so), the patch would suddenly jump
=armv6 and -mfpu=vfp. Option -mfpu=vfpv2 is not allowed. I would
be happy to do further testing with compiler options, if you know
some. The big-or-small checks are rather expensive for RPi, that's
what I've found.
Katja
On Sun, Jan 20, 2013 at 8:24 PM, Miller Puckette m...@ucsd.edu wrote
...@chnry.net mailto:c...@chnry.net
wrote:
edirol uca222 works great.
cheers
c
Le 04/01/2013 17:49, Miller Puckette a écrit :
The best ide I got was from the Griffin iMic (thanks
to Joe Deken over
That's a good idea... I'll stick it on my list (but I've got years of
backlog so it won't happen fast I'm afraid).
cheers
Miller
On Tue, Jan 15, 2013 at 05:15:55PM +0100, Fero Kiraly wrote:
hallo,
It is possibile for pd developers to make this thing ? :
When I have an abstraction object
Hi all -
Time for the first Pd 0.44 bug fix. I changed the choice of default API
(so that MMIO is preferred to ASIO on windows; ALSA before jack on linux,
and core audio before jack on Mac OSX - this is so that first-time Pd users
who haven't yet chosen an API are reasonably likely to get audio
Hi Katja -
There's one example of this in sigfft_dspx() - a complex FFT that 'natively'
works on 2 signals in-place but has to deal with various cases in which
buffers get re-used. It's ugly but the basic idea is first to get the
inputs copied to the outputs (unless they're already there in the
are in place so copying the
right channel input to output should do it. Is there any reason to
prefer copy_perform() over memcpy()? I'm trying to make the most
efficient reverb for RPi Co.
Katja
On Fri, Jan 11, 2013 at 7:57 PM, Miller Puckette m...@ucsd.edu wrote:
Hi Katja -
There's one
Cool... I'm guessing it's now stable enough to call it the official 0.44...
I'll get to work on that in a few hours.
cheers
Miller
On Sun, Jan 06, 2013 at 06:26:29PM +0100, Pierre-Olivier Boulant wrote:
On 06/01/2013 17:02, Hans-Christoph Steiner wrote:
On Jan 6, 2013, at 10:21 AM,
101 - 200 of 685 matches
Mail list logo
