[PD] [textfile] behavior
Roman Haefeli
reduzierer at yahoo.de
Sun Mar 4 18:33:54 CET 2007
On Sun, 2007-03-04 at 12:11 -0500, David F. Place wrote:
> On Mar 4, 2007, at 11:52 AM, Roman Haefeli wrote:
>
> > hi david
> >
> > i had a look at your patch, but i didn't come to a solution,
> > respectively i wasn't able to figure out what the problem exactly is.
>
> In the file big.txt, the process stops before it reaches the "control
> mark" record. I think that there may be a limited amount of
> computation allowed in a control cycle. Does Pd just abort the
> control cycle if it runs out of time? I tried this also with audio
> turned off and saw the same behavior.
i don't think, that pd just aborts a control-cycle silently. if so, then
it would print at least a message like 'stack overflow'.
>
> Perhaps you are not able to reproduce the behavior? If you click
> [read small.txt( then [4( you should see:
>
> cue: This is mark 4
i totally saw your problem, but i am not able to sort everything out, so
that i can be sure to understand, what really happens.
>
> If you click [read big.txt( the [4( you will see something else and
> that is wrong.
how can you be sure, that it is wrong? possibly your mind is capaple of
much more, but i tend to believe, that it's a fault of the patch, not of
pd. but why make it complicate, when it could be so clear and easy?
roman
>
> >
> > however, i think, what you want to achieve could be implemented much
> > easier, particularly easier to read. what makes it very difficult to
> > read, is the deep deepness of the message structure, though at first
> > glance it doesn't look like a very complicated patch. for example:
> > before the right tree of a [trigger] is finished, it's 'banged' again,
> > so that it is triggered several times, before the left tree starts the
> > execution. my mind is far too less capable of beeing aware, what the
> > actual state on each step really is.
> >
> > i didn't make an example patch (ask me, if you want me to do so),
> > but i
> > have some ideas for another approach. i think i would 'control' the
> > [textfile] with an [until]-object. when triggered, [until] keeps
> > firing
> > 'bang's until you stop it. send the bangs to [textfile], so that on
> > each bang it's going one line further. you could parse the output of
> > [textfile], that when the message, you are looking for, is coming out
> > [textfile], you could stop [until], and you have the 'cue' at the
> > desired position.
> >
> > hope that helps...
> >
> > roman
> >
> > On Sat, 2007-03-03 at 20:50 -0500, David F. Place wrote:
> >> Pd:
> >>
> >> I am writing a sequencer using Pd and have bumped into the following
> >> problem. I would like to be able to position the textfile object to
> >> start playback from a certain record. The approach I have taken
> >> works
> >> for small files, but breaks down for large files. I've abstracted
> >> the
> >> behavior into the attached patch. textfileBug.pd
> >>
> >> I suspect that it reflects some inadequacy in my understanding of Pd,
> >> but just in case it is a bug, here are my system specs.
> >>
> >> Pd 0.41
> >> Fedora Core 4
> >> 64-bit AMD
> >>
> >> Thanks,
> >> dP
> >
> >
> >
> >
> >
> >
> >
> > ___________________________________________________________
> > Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo!
> > Mail: http://mail.yahoo.de
>
> --o-------o-o-o---o-o-o---
> David F. Place
> mailto:d at vidplace.com
>
>
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
More information about the Pd-list
mailing list