> > - using Jack in RT mode
> > - increasing buffer size
> > - using dual-core computer
> > - using "renice" on the pd process
>
> this suggestions won't solve the mentioned problems for sure (besides
> increasing the buffer to a huge amount). since the problems arise
> withing pd itself, you canno
Tim Blechmann wrote:
> there are applications which are able to load soundfiles in a
> realtime-safe way.
see, for example, ableton live
--
damian stewart | +44 7854 493 796 | [EMAIL PROTECTED]
frey | live art with machines | http://www.frey.co.nz
__
ciao matteo
you are speaking from my hear! this is exactly what i mean (without
critizing pd at all).
roman
On Wed, 2007-06-06 at 01:48 +0200, Matteo Sisti Sette wrote:
> Frank wrote:
>
> > Just a note: Many people all over the world are using Pd in live
> > performances, which proves that it
Uh oh, don't flame me now!
;-)
~Kyle
On 6/5/07, Matteo Sisti Sette <[EMAIL PROTECTED]> wrote:
> Frank wrote:
>
> > Just a note: Many people all over the world are using Pd in live
> > performances, which proves that it is a suitable tool for this.
> > That's it's not bug-free and has room for im
Frank wrote:
> Just a note: Many people all over the world are using Pd in live
> performances, which proves that it is a suitable tool for this.
> That's it's not bug-free and has room for improvements is a different
> story.
And also:
> there is not a single piece of
> free software in its rea
Hallo,
marius schebella hat gesagt: // marius schebella wrote:
> Frank Barknecht wrote:
>
> > My point is: We shouldn't make Pd worse than it actually is.
>
> My point is: We should make Pd better than it actually is. ;)
Good point. Lets not make Pd worse than it is, lets make it better.
Cia
Roman wrote:
correct me as well, if i am wrong, but there shouldn't be a need for
rebuilding the dsp tree when loading a soundfile using [sndfiler], since
it just copies data from disk/soundfile to memory/table. the dsp tree
should stay the same. perhaps the same approach would work for [text
Frank Barknecht wrote:
> My point is: We shouldn't make Pd worse than it actually is.
My point is: We should make Pd better than it actually is.
;)
marius.
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.in
On Tue, 2007-06-05 at 18:15 +0200, Frank Barknecht wrote:
> Hallo,
> Matteo.sistisette hat gesagt: // Matteo.sistisette wrote:
>
> > That is definitely something I have already heard before: that pd is not
> > suitable or reliable for live/presentation.
> > If a system which is entirely focused on
Hallo,
marius schebella hat gesagt: // marius schebella wrote:
> Frank Barknecht wrote:
>
> > Just a note: Many people all over the world are using Pd in live
> > performances, which proves that it is a suitable tool for this.
>
> not really, it just proves, that some people know how to handle
On Tue, 2007-06-05 at 17:26 +0200, Roman Haefeli wrote:
>
> > > correct me as well, if i am wrong, but there shouldn't be a need
> for
> > > rebuilding the dsp tree when loading a soundfile using [sndfiler],
> > > since
> > > it just copies data from disk/soundfile to memory/table. the dsp
> tree
Frank Barknecht wrote:
> Just a note: Many people all over the world are using Pd in live
> performances, which proves that it is a suitable tool for this.
not really, it just proves, that some people know how to handle the
problems, be it knowing about the limitations or just not caring about
Just a note: Many people all over the world are using Pd in live
performances, which proves that it is a suitable tool for this.
That's it's not bug-free and has room for improvements is a different
story.
Agreed!
k
___
PD-list@iem.at mailing list
U
On 6/5/07, Tim Blechmann <[EMAIL PROTECTED]> wrote:
> loading a soundfile in the background is trivial ... just the way the pd
> interpreter uses them (instantiate a patch / resort the dsp chain) isn't
> realtime safe ...
Even applications like Logic do not create new audio threads while
audio is
Hallo,
Matteo.sistisette hat gesagt: // Matteo.sistisette wrote:
> That is definitely something I have already heard before: that pd is not
> suitable or reliable for live/presentation.
> If a system which is entirely focused on REAL-TIME isn't suitable for
> presenting/live situations, then it is
On Tue, 2007-06-05 at 10:20 -0400, Stephen Sinclair wrote:
> > > all this issues cannot be 'worked around' within pd, which makes pd
> > > sometimes not very suitable for presenting/live situations.
>
> I'd be curious to know what happens when you try things like:
>
> - using Jack in RT mode
>
On Tue, 2007-06-05 at 10:26 -0500, chris clepper wrote:
> On 6/5/07, Tim Blechmann <[EMAIL PROTECTED]> wrote:
>
> > loading a soundfile in the background is trivial ... just the way the pd
> > interpreter uses them (instantiate a patch / resort the dsp chain) isn't
> > realtime safe ...
>
> Even
On Tue, 2007-06-05 at 17:16 +0200, Tim Blechmann wrote:
> On Tue, 2007-06-05 at 17:00 +0200, Roman Haefeli wrote:
> > On Tue, 2007-06-05 at 07:41 -0700, Phil Stone wrote:
> >
> > > I'm wondering if the threaded [sndfiler] object could be adapted to
> > help
> > > with this particular problem. Ap
On Tue, 2007-06-05 at 17:00 +0200, Roman Haefeli wrote:
> On Tue, 2007-06-05 at 07:41 -0700, Phil Stone wrote:
>
> > I'm wondering if the threaded [sndfiler] object could be adapted to
> help
> > with this particular problem. Apparently, it doesn't work so well
> for
> > soundfiles (please corr
On Tue, 2007-06-05 at 07:41 -0700, Phil Stone wrote:
> I'm wondering if the threaded [sndfiler] object could be adapted to help
> with this particular problem. Apparently, it doesn't work so well for
> soundfiles (please correct me if I'm wrong), because the dsp tree needs
> to be rebuilt anyw
> I'm wondering if the threaded [sndfiler] object could be adapted to help
> with this particular problem. Apparently, it doesn't work so well for
> soundfiles (please correct me if I'm wrong), because the dsp tree needs
> to be rebuilt anyway, causing dropouts. However, could it work as a way
> > all this issues cannot be 'worked around' within pd, which makes pd
> > sometimes not very suitable for presenting/live situations.
I'd be curious to know what happens when you try things like:
- using Jack in RT mode
- increasing buffer size
- using dual-core computer
- using "renice" on the
Roman Haefeli wrote:
> On Mon, 2007-06-04 at 22:04 +0200, Matteo Sisti Sette wrote:
>
>> Hi,
>>
>> I always thought that in PD, "process" (i.e. dsp and control processing) had
>> the priority over GUI rendering, in such a way that drawing the gui would
>> NEVER cause audio clicks although this
> there are other issues as well, which cause drop outs, that might be
> avoidable:
>
> all this issues cannot be 'worked around' within pd, which makes pd
> sometimes not very suitable for presenting/live situations.
That's exactly what I meant in my previous message in the "pd evolution"
threa
Hi Matteo,
On Mon, 2007-06-04 at 22:04 +0200, Matteo Sisti Sette wrote:
> I always thought that in PD, "process" (i.e. dsp and control processing) had
> the priority over GUI rendering, in such a way that drawing the gui would
> NEVER cause audio clicks although this means there's no warranty ab
On Mon, 2007-06-04 at 22:04 +0200, Matteo Sisti Sette wrote:
> Hi,
>
> I always thought that in PD, "process" (i.e. dsp and control processing) had
> the priority over GUI rendering, in such a way that drawing the gui would
> NEVER cause audio clicks although this means there's no warranty about
Hi,
I always thought that in PD, "process" (i.e. dsp and control processing) had
the priority over GUI rendering, in such a way that drawing the gui would
NEVER cause audio clicks although this means there's no warranty about how
much gui rendering may be delayed.
To my great disappointment, I
27 matches
Mail list logo
