[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