Hi all,
I'm trying to resize an array after doing a tabwrite~ to it, like soundfiler can automatically. This seems to me to be a trivial thing to do, but I can't figure out how to get the number of elapsed samples. I considered using a [timer], but last time I used that it was extremely innaccurate, especially with high system loads.
Would a combination of [realtime] and [samplerate~] be accurate? I guess I shy away from deducing the number of elapsed samples, as I'd rather get the true number somehow--but this is the only way I can figure it out so far. Any tips?
Thanks much, Ian
Hallo, Ian Smith-Heisters hat gesagt: // Ian Smith-Heisters wrote:
I'm trying to resize an array after doing a tabwrite~ to it, like soundfiler can automatically. This seems to me to be a trivial thing to do, but I can't figure out how to get the number of elapsed samples.
You could maybe try: [bang~] * [blocksize~]
Ciao
Frank Barknecht _ ______footils.org__
Zitiere Ian Smith-Heisters heisters@0x09.com:
Hi all,
I'm trying to resize an array after doing a tabwrite~ to it, like soundfiler can automatically. This seems to me to be a trivial thing to
do, but I can't figure out how to get the number of elapsed samples. I
considered using a [timer], but last time I used that it was extremely
innaccurate, especially with high system loads.
[timer] gets you the logical(!) time between 2 events in pd. this is exactly what you want!
i do not think that there is really an inaccuracy, probably the problem lies somewhere else ?
the only problem i can think of, is when you loose some ticks because of very high system load (but then you will get clicks and the time lost might be the smallest problem)
Would a combination of [realtime] and [samplerate~] be accurate? I guess
realtime measures the elapsed time viewed from the "world outside" (this is becoming relativistic); since you are not interacting with the world outside (apart from dac/adc which is ok) [realtime] might not be the way to go.
I shy away from deducing the number of elapsed samples, as I'd rather get the true number somehow--but this is the only way I can figure it out so far. Any tips?
you will never get below 64 samples in accuracy anyhow (no matter whether you try with [timer], [realtime], [time] or whatever
mfg.acew. IOhannes
I did some experimenting with this technique, and it seems it will be just fine. I'm not sure where I got the impression timer wouldn't be accurate enough, but I was obviously wrong ;)
-Ian
zmoelnig@iem.at wrote:
Zitiere Ian Smith-Heisters heisters@0x09.com:
Hi all,
I'm trying to resize an array after doing a tabwrite~ to it, like soundfiler can automatically. This seems to me to be a trivial thing to
do, but I can't figure out how to get the number of elapsed samples. I
considered using a [timer], but last time I used that it was extremely
innaccurate, especially with high system loads.
[timer] gets you the logical(!) time between 2 events in pd. this is exactly what you want!
i do not think that there is really an inaccuracy, probably the problem lies somewhere else ?
the only problem i can think of, is when you loose some ticks because of very high system load (but then you will get clicks and the time lost might be the smallest problem)
Would a combination of [realtime] and [samplerate~] be accurate? I guess
realtime measures the elapsed time viewed from the "world outside" (this is becoming relativistic); since you are not interacting with the world outside (apart from dac/adc which is ok) [realtime] might not be the way to go.
I shy away from deducing the number of elapsed samples, as I'd rather get the true number somehow--but this is the only way I can figure it out so far. Any tips?
you will never get below 64 samples in accuracy anyhow (no matter whether you try with [timer], [realtime], [time] or whatever
mfg.acew. IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
I'm trying to resize an array after doing a tabwrite~ to it, like soundfiler can automatically. This seems to me to be a trivial thing to do, but I can't figure out how to get the number of elapsed
i wouldn't recommend resizing tables on the fly, since iirc it will require the dsp chain to be recompiled ...
cheers... tim
Tim Blechmann wrote:
i wouldn't recommend resizing tables on the fly, since iirc it will require the dsp chain to be recompiled ...
well, i would rather recommend to not recompile the dsp-chain when resizing a table.
as far as i know, all objects that access tables check for validity and size of the table in their perform()-routine.
mfg.asd.r IOhannes
i wouldn't recommend resizing tables on the fly, since iirc it will require the dsp chain to be recompiled ...
well, i would rather recommend to not recompile the dsp-chain when resizing a table.
the problem is pd's handling of arrays. objects using tables contain the pointer to the data, not the pointer to the structure of pointer to data and size. basically every time the position of the data in the memory changes, the dsp chain has to be recompiled. imo that's a design fault!
i made some suggestions how to change that, but it seemed, miller hasn't been interested in that ... so this stupid behaviour won't be changed for some time ...
basically every time the position of the data in the memory changes, the dsp chain has to be recompiled
every message sent to tables will cause the dsp chain to be recompiled. for the threaded soundfiler i implemented a resize message, that does all the memory operations (allocation, copying, freeing) in a seperate thread, but still, the dsp chain has to be recompiled ... my idea was to have a synchronous behaviour (messages to arrays) and a threaded (clickfree) behaviour (soundfiler)
cheers ... tim
Tim Blechmann wrote:
i wouldn't recommend resizing tables on the fly, since iirc it will require the dsp chain to be recompiled ...
well, i would rather recommend to not recompile the dsp-chain when resizing a table.
the problem is pd's handling of arrays. objects using tables contain the pointer to the data, not the pointer to the structure of pointer to data
all right, i thought pd_findbyclass() was called in the perform(); checking in the code proved you are right.
mfg.itu.asa IOhannes
Yes. Hm. As it turned out my method made Pd segfault. I couldn't isolate the problem, but gdb pointed at tabread4~, so it was probably in the fact that I was resizing the array and trying to read from it at about the same time ;) If anyone's interested in the nitty gritty I'd be glad to post it, i just didn't want to waste anyone's time since I couldn't isolate it to a simple patch.
The fact that soundfiler does it in a separate thread gives me pause, since my alternative still included resizing on the fly, just not doing it to the same array I'm reading from. Would it be an easy task for me to open the soundfiler code, and take out everything but resize, so I could have a "resize array in separate thread" external? I know it wouldn't fix the recompilation issues, but it would be better than nothing, no? Or I could just have a bunch of enormous arrays sitting around in case I want to use them..
Best, ian
Tim Blechmann wrote:
I'm trying to resize an array after doing a tabwrite~ to it, like soundfiler can automatically. This seems to me to be a trivial thing to do, but I can't figure out how to get the number of elapsed
i wouldn't recommend resizing tables on the fly, since iirc it will require the dsp chain to be recompiled ...
cheers... tim
The fact that soundfiler does it in a separate thread gives me pause, since my alternative still included resizing on the fly, just not doing it to the same array I'm reading from. Would it be an easy task for me to open the soundfiler code, and take out everything but resize, so I could have a "resize array in separate thread" external?
you could try devel_0_38 and the |resize( message to the threaded soundfiler... i'm not sure, if it's working, since i did some changes to the thread synchronisation and haven't tried it since then...
i'll possibly have a look at it, when having more time (probably end of march)
cheers... tim
Hallo, Ian Smith-Heisters hat gesagt: // Ian Smith-Heisters wrote:
Yes. Hm. As it turned out my method made Pd segfault. I couldn't isolate the problem, but gdb pointed at tabread4~, so it was probably in the fact that I was resizing the array and trying to read from it at about the same time ;) If anyone's interested in the nitty gritty I'd be glad to post it, i just didn't want to waste anyone's time since I couldn't isolate it to a simple patch.
Couldn't you avoid resizing altogether by e.g. storing the length of the recorded data into a float, and then only read as far as that?
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: fqdn _ http://footils.org/cms/show/38
Yes, that's my secondary solution, and actually what I ended up doing for the time being. It seems inefficient to me, however, to have a bunch of arrays sitting around that I'm not using entirely. While I won't run into a problem right away with a gig of memory, it won't be too long with such an inefficient model. However, this may be more efficient than trying to resize them on the fly. I'm always looking for the "right" or "elegant" way to do things in programming, but sometimes the way that works is elegant because it works at all.
-Ian
Frank Barknecht wrote:
Hallo, Ian Smith-Heisters hat gesagt: // Ian Smith-Heisters wrote:
Yes. Hm. As it turned out my method made Pd segfault. I couldn't isolate the problem, but gdb pointed at tabread4~, so it was probably in the fact that I was resizing the array and trying to read from it at about the same time ;) If anyone's interested in the nitty gritty I'd be glad to post it, i just didn't want to waste anyone's time since I couldn't isolate it to a simple patch.
Couldn't you avoid resizing altogether by e.g. storing the length of the recorded data into a float, and then only read as far as that?
Ciao
Hallo, Ian Smith-Heisters hat gesagt: // Ian Smith-Heisters wrote:
Yes, that's my secondary solution, and actually what I ended up doing for the time being. It seems inefficient to me, however, to have a bunch of arrays sitting around that I'm not using entirely. While I won't run into a problem right away with a gig of memory, it won't be too long with such an inefficient model. However, this may be more efficient than trying to resize them on the fly. I'm always looking for the "right" or "elegant" way to do things in programming, but sometimes the way that works is elegant because it works at all.
In his keynote at Graz Miller at one point said - and quite impressed me with it -, that for a certain problem related to data structures, he already could think of a lot of *intelligent* solutions, but that he hadn't yet found a *stupid* solution, and thus didn't implement any solution yet.
I doubt that keeping track of the length qualifies as a "stupid" solution, but it is stupider than the intelligent solution which would be to wait for array resizing to finally work flawlessly. ;)
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: fqdn _ http://footils.org/cms/show/38
-
Frank Barknecht -
Ian Smith-Heisters -
IOhannes m zmoelnig -
Tim Blechmann -
zmoelnig＠iem.at