I just recently figured out the whole graph on parent thing (after like 10 months of learning Pd... finally!!!) but anyway, I was trying to take some of the elements of a big sequencer patch I made and separate them into their own abstractions (is that the correct use of the term?) so I can drop in different parts and effects and whatnot......

So I was adding these different parts into a new file, and everything runs fine, but when I added this loop recorder element it starts running REAAAAALLY slow. Like, I'll try to scroll the screen over and it won't respond until about 5-10 seconds later. The loop recorder does not have very much in terms of gui (just a few sliders and toggles) so I don't think that is it. Also, I don't get any sort of error messages or overflows. Just wondering what it could be if I'm not getting any errors.

I am planning on uploading some stuff soon since I keep downloading other people's stuff to study. I haven't really contributed anything all this time. Thanks.

Well, I only noticed this once, and the effect was minor, but on a mac, someone's pitch transposition patch from this forum, performed a little better when the abstraction that contained the guts was converted into a sub patch instead (i.e. copying and pasted from a new file into a [pd subpatch] object.

sorry i can't be more specific about the issue but i guess you might want to try putting it into subpatches rather than calling on new files/abstractions. you still get the benefits of modular programming this way... just not modular file organisation

I don't know if this will make a difference, since it's likely hidden, but are you using arrays or tables to hold the sound for the looper? Arrays, as I understand, are some of the most inefficient gui elements in Pd. I read on the list a while back that changing one sample in an array requires it to be erased and completely redrawn, because of the way it is programmed. I have noticed that patches with arrays in them scroll slower, but I've only noticed this when the array is visible. But if it is in the same window as the gui stuff in your abstraction, it might be good to dump it in a subpatch, as arif suggested. Or try just converting it to a

i am using two arrays (one for left and one for right) and i think this was mainly due to wanting to be able to arbitrarily start and stop recording the audio for the loop. Maelstorm, i remember you helping me out a lot with figuring this out (thanks again!!!), and i think i do remember you saying that using arrays for this can be troublesome. i was examining it more the other night and i think i may have somehow cleared it up by deleting some unnecessary junk, but not entirely sure.

however, another weird thing happens sometimes... i have the arrays on the graph on parent abstraction named "grabberL" and "grabberR" with [start( and [stop( messages going into two writesf~'s and then two [read -resize('s going into [soundfiler] and blah blah blah.... basically just trying to give you an idea of the method i'm using (which works fine)...... but the weird thing that happens occasionally is i will at some point notice that on my main gui window i will notice that the two "grabberL" and "grabberR" arrays appear off to the side. i'm wondering if that may be a clue as to why i am having some problems. why would these two arrays appear when i already have them hidden away on the abstraction?

Hmm...I think this might be another weird thing with how arrays are drawn. I've noticed even if you put a [cnv] or something on top of an array, the array still insists on being drawn in the foreground. Maybe it's a similar problem with abstractions. If you don't need to see the arrays, delete them and replace them with

Array redrawing is a problem as is currently being fixed in the gui rewrite :
http://puredata.info/dev/GuiIdeas (check the bottom of the page)

I think....
:0

I'm so excited about the gui rewrite.

i did end up replacing the arrays with tables, which i believe made things better. it did occur to me that i think i was having that issue with the arrays appearing where they shouldn't be when i had right-clicked on the abstraction and opened it and was messing with it. i think that may have caused two instances of it being open and when i was using my keyboard keys to operate it it may have created a 2nd set of the arrays... or something.

i thought of this earlier today and it sounded a lot more plausible in my head at the time, but how i'm explaining it now sounds ignorant. anyway, i think i fixed the problem, or at least worked around it for now. thanks everybody.

have been sorting out a similar problem... i'm in a process of building a loop sampler/mangler and the gui started to slow things down quite a bit. i had used sliders to indicate loop start/stop/play points but learned from here that the slider-object is very cpu-consuming.. the sound was ok but the screen was pretty much frozen..

i first replaced the slider-indicators with simple number boxer. that of course took away the problem but wasn't very infomative...
i decided to try the [grid] object (resizing it to 6 pixels hight/600 pixels wide) as an alternative and found it much better.

any other ideas? is there a(nother) way to draw the contents of a table/hidden array? or does it make any difference for just simply using a visible array? (the array contents are only changing then a new sample is recorded).

edit: and i'm running pd 0.40.3-ext on osx 10.4 and ppc processor.