Hi all, How feasible would a "prev" message to [pointer] be (naturally, this would be the complement to the "next" message, outputting the previous pointer in the list)?
I'm very keen to make a "scrubbable" sequencer that can be driven by [line]s rather than the usual [del]-based arrangement, but my current method of just dumping the entire data-structure on every tick and searching for elements whose x-value matches the current time requires twice the CPU I have available.
I thought about mirroring the data-structure and traversing one or the other depending on direction, but I think this will get untenable quickly.
Cheers Luke
Horribly unfeasible -- the data are stored as a singly linked list. Going back would require searching forward from the beginning.
cheers Miller
On Mon, Apr 14, 2008 at 11:36:13AM -0700, Luke Iannini (pd) wrote:
Hi all, How feasible would a "prev" message to [pointer] be (naturally, this would be the complement to the "next" message, outputting the previous pointer in the list)?
I'm very keen to make a "scrubbable" sequencer that can be driven by [line]s rather than the usual [del]-based arrangement, but my current method of just dumping the entire data-structure on every tick and searching for elements whose x-value matches the current time requires twice the CPU I have available.
I thought about mirroring the data-structure and traversing one or the other depending on direction, but I think this will get untenable quickly.
Cheers Luke
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Mon, Apr 14, 2008 at 2:33 PM, Miller Puckette mpuckett@imusic1.ucsd.edu wrote:
Horribly unfeasible -- the data are stored as a singly linked list. Going back would require searching forward from the beginning.
cheers Miller
I thought as much, thanks for the answer. Would built-in "search" methods be any faster than what I describe (dumping all pointers, [get]ting and [sel]ecting looking for one with a particular value)?
Maybe you can use an array field to store your events instead? You can index this by an integer.
Ciao
Frank
This was on the "tip of my brain" : ). Thanks for prodding me into it, I'm trying it out now and I'll let you know how it goes. It will also be a natural fit to adding "note layers" that can be toggled on and off or manipulated individually, so that's cool too.
As an aside, I'd like to start a "ds-abs" collection soon to go alongside list-abs. I've got a few in SVN that I'll be splitting out soon, and it would be great if anyone wants to contribute more.
Cheers Luke
That's what I'd do. Someday I'll implement an 'nth' method for pointer (and search methods too) that will make this easier. As usual, just gotta figure out the most robust design.
cheers M
On Mon, Apr 14, 2008 at 05:33:54PM -0700, Luke Iannini (pd) wrote:
On Mon, Apr 14, 2008 at 2:33 PM, Miller Puckette mpuckett@imusic1.ucsd.edu wrote:
Horribly unfeasible -- the data are stored as a singly linked list. Going back would require searching forward from the beginning.
cheers Miller
I thought as much, thanks for the answer. Would built-in "search" methods be any faster than what I describe (dumping all pointers, [get]ting and [sel]ecting looking for one with a particular value)?
Maybe you can use an array field to store your events instead? You can index this by an integer.
Ciao
Frank
This was on the "tip of my brain" : ). Thanks for prodding me into it, I'm trying it out now and I'll let you know how it goes. It will also be a natural fit to adding "note layers" that can be toggled on and off or manipulated individually, so that's cool too.
As an aside, I'd like to start a "ds-abs" collection soon to go alongside list-abs. I've got a few in SVN that I'll be splitting out soon, and it would be great if anyone wants to contribute more.
Cheers Luke
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Luke Iannini (pd) hat gesagt: // Luke Iannini (pd) wrote:
I'm very keen to make a "scrubbable" sequencer that can be driven by [line]s rather than the usual [del]-based arrangement, but my current method of just dumping the entire data-structure on every tick and searching for elements whose x-value matches the current time requires twice the CPU I have available.
I thought about mirroring the data-structure and traversing one or the other depending on direction, but I think this will get untenable quickly.
Maybe you can use an array field to store your events instead? You can index this by an integer.
Ciao
Frank
-
Frank Barknecht -
Luke Iannini (pd) -
Miller Puckette