Hi,
Miller Puckette wrote:
> I have this problem too... I'm baffled for the moment but want to figure it
> out and fix it :)
Great. By the way, I have followed IOhannes' recommendation and posted
the issue to the bugtracker (#2978457), including the latest version of
the example patch and a descr
I have this problem too... I'm baffled for the moment but want to figure it
out and fix it :)
Miller
On Mon, Mar 29, 2010 at 10:39:44AM +0100, Florian Hollerweger wrote:
> Hi,
>
> IOhannes m zmoelnig wrote:
> > one thing you you try, is to explicitely set the samplerate at startup:
> > try "pd -n
Hi,
IOhannes m zmoelnig wrote:
> one thing you you try, is to explicitely set the samplerate at startup:
> try "pd -nogui -r 44100"
I remember this trick having been suggested also for the "no
[loadbang]->[;pd dsp 1( under -nogui" problem. As there, it does not
work for me in the current situatio
hi
On 2010-03-27 17:11, Derek Holzer wrote:
> Hey Flo,
>
> IOhannes accused me of making this up when I posted it a week or so ago
> ;-)
> Thanks for posting a documented example. Yes it does seem like
> voodoo doesn't it?
i haven't tried the patch yet, but indeed there seems to be a problem,
Hi Georg, hi list,
Georg Werner wrote:
> FYI, your patch works with -nogui and winxp even without the [switch~].
> Pd version 0.41.4-extended-20090509
Thank you so much for this revealing contribution. I can indeed confirm
that Windows XP seems to be free from the -nogui audio initialisation
prob
Hi,
FYI, your patch works with -nogui and winxp even without the [switch~].
Pd version 0.41.4-extended-20090509
Matteo Sisti Sette:
> 3) _Every_ single abstraction that contains any dsp objects (or some
> "ascendant" of it), always contains a [switch~], which is loadbanged
> to off, and later ex
So having a [switch~] would solve all the -nogui initialization
troubles? That is valuable to know. Thanks.
that was just a guess. we actually got around it by modifying pd code.
florian, sorry i can not post the link, because it wasn't me who did the
hack.
Hi,
Roman Haefeli wrote:
> So having a [switch~] would solve all the -nogui initialization
> troubles? That is valuable to know. Thanks.
I am afraid I cannot confirm this, as illustrated in the attached
example. This is the same patch I posted yesterday, extended by a
loadbanged [switch~].
Or am
Hi,
hard off wrote:
> however, when run in -nogui mode, the samplerate is set after the
> delayline code, and the calculation for the delayline is set with
> samplerate = 0
This sounds reasonable - thanks for illuminating this issue!
> our hack was just to tweak the pd code to have a hardcoded s
On Sun, 2010-03-28 at 19:06 +0900, hard off wrote:
> matteo, by putting a [switch~] in each patch, it could possibly
> alleviate the problem, because i assume the [switch~] object forces
> samplerate to be recalculated.
So having a [switch~] would solve all the -nogui initialization
troubles? That
matteo, by putting a [switch~] in each patch, it could possibly alleviate
the problem, because i assume the [switch~] object forces samplerate to be
recalculated.
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata
i also ran into this problem.
if i can remember correctly, the cause was something along the lines of:
the pd samplerate needs to be set before the delayline code is initiated.
if pd is run in gui mode, then the gui initialization forces the order
correctly.
however, when run in -nogui mode, the
On Sat, 2010-03-27 at 17:11 +0100, Derek Holzer wrote:
> Hey Flo,
>
> IOhannes accused me of making this up when I posted it a week or so ago
> ;-) Thanks for posting a documented example. Yes it does seem like
> voodoo doesn't it?
>
I also once stumbled across the problem [delread~] not being
Somebody wrote:
>> The way I remember it, anything to do with tables or other allocated
>> memory can break with -nogui. [tabwrite~], [tabread~], [delwrite~],
>> [delread~], [vd~] etc etc
I'm very curious about this issue and quite surprised, since I have been
using -nogui for a long time,
Hi Matt,
Matt Barber wrote:
> what I was suggesting was that the -nogui might be
> interfering with the implementation of the delay lines themselves, not
> specifically with [delread~].
I agree, the [delread~] behavior under -nogui seems to be the/a symptom
of a cause which is probably located at
Right -- what I was suggesting was that the -nogui might be
interfering with the implementation of the delay lines themselves, not
specifically with [delread~].
Matt
On Sat, Mar 27, 2010 at 2:19 PM, Florian Hollerweger wrote:
> Hi Matt,
>
> Matt Barber wrote:
>> Are we sure this is a problem wit
Are we sure this is a problem with [delread~]? There's a related bug
where if you open a patch which has delays at one sample rate, if you
then change the sample rate in the preferences it won't reallocate the
delay buffers, so if you increase the sample rate, you're left with
shorter delay lines
Hi Derek,
Derek Holzer wrote:
> IOhannes accused me of making this up when I posted it a week or so ago
> ;-)
Gee, I swear I searched the archives first :-]
> Yes it does seem like voodoo doesn't it?
Since the discovery of the infamous "no [loadbang]->[;pd dsp 1] under
-nogui" bug (posted on th
Hey Flo,
IOhannes accused me of making this up when I posted it a week or so ago
;-) Thanks for posting a documented example. Yes it does seem like
voodoo doesn't it?
D.
On 3/27/10 3:13 PM, Florian Hollerweger wrote:
Dear list,
When starting Pd with the -nogui flag, [delread~] seems to ign
Dear list,
When starting Pd with the -nogui flag, [delread~] seems to ignore its
float input (specifying the delay time in ms) and instead produce sounds
which resemble a [delwrite~]/[delread~] loop at very short (one block of
audio?) delay times.
Attached is a minimal example. (Attention, this w
20 matches
Mail list logo
