Dear list,
I am working on a small patch which stores simple events in a table to trigger sounds later on. I would like to be able to edit the content of my table easily, which requires scrolling it, zooming in, and eventually editing the content.
I have found away of scrolling the content, but it is very slow with relatively big tables (hem, even with a table with 20 000 samples...). Please see the example attached.
I have 2 questions :
- Is there a more efficient way of doing this ? Copying only part of the
content is worse (i've tried). 2) Can I prevent the content of the table from spilling over the table to right of the left ? I get the same behaviour in a GOP, and putting a canvas next to the table to cover it doesn't work because the table content gets redrawn on top of it.
This leads me to a more general question about something i've found in the help : "5 Wave editing: with proper manipulation of array data, Pd can be fully functional wave editor, complete with mouse-clickable cut-n-paste, pitch-shift, time expansion, down/upsampling, and other tools typically found in commercial wave editors." This has always sounded very appealing to me, but i wonder how realistic this statement is... unless i'm ignoring 80 % of what can be done with tables in Pd.
Cheers,
Pierre.
From that help patch:
#X text 12 115 HELP_PATCH_AUTHORS Updated for Pd 0.38-2. Jonathan Wilkes revised the patch to conform to the PDDP template for Pd version 0.42.
I did the refactoring of that patch, but I'm not sure who wrote what you're quoting.
I'd say that statement is false and should be removed.
-Jonathan
On Sunday, March 2, 2014 10:47 AM, Pierre Massat pimassat@gmail.com wrote:
Dear list,
I am working on a small patch which stores simple events in a table to trigger sounds later on. I would like to be able to edit the content of my table easily, which requires scrolling it, zooming in, and eventually editing the content.
I have found away of scrolling the content, but it is very slow with relatively big tables (hem, even with a table with 20 000 samples...). Please see the example attached.
I have 2 questions :
- Is there a more efficient way of doing this ? Copying only part of the content is worse (i've tried).
- Can I prevent the content of the table from spilling over the table to right of the left ? I get the same behaviour in a GOP, and putting a canvas next to the table to cover it doesn't work because the table content gets redrawn on top of it.
This leads me to a more general question about something i've found in the help : "5 Wave editing: with proper manipulation of array data, Pd can be fully functional wave editor, complete with mouse-clickable cut-n-paste, pitch-shift, time expansion, down/upsampling, and other tools typically found in commercial wave editors." This has always sounded very appealing to me, but i wonder how realistic this statement is... unless i'm ignoring 80 % of what can be done with tables in Pd.
Cheers,
Pierre.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Jonathan,
I found it following this path : help for [tabwrite] --> More_Info --> all_about_arrays --> Common uses for arrays in Pd Bummer, I thought somebody would come up with a secret table manipulation technique that would make this statement true...
Cheers,
Pierre.
2014-03-02 19:33 GMT+01:00 Jonathan Wilkes jancsika@yahoo.com:
From that help patch: #X text 12 115 HELP_PATCH_AUTHORS Updated for Pd 0.38-2. Jonathan Wilkes revised the patch to conform to the PDDP template for Pd version 0.42.
I did the refactoring of that patch, but I'm not sure who wrote what you're quoting.
I'd say that statement is false and should be removed.
-Jonathan
On Sunday, March 2, 2014 10:47 AM, Pierre Massat pimassat@gmail.com wrote: Dear list,
I am working on a small patch which stores simple events in a table to trigger sounds later on. I would like to be able to edit the content of my table easily, which requires scrolling it, zooming in, and eventually editing the content.
I have found away of scrolling the content, but it is very slow with relatively big tables (hem, even with a table with 20 000 samples...). Please see the example attached.
I have 2 questions :
- Is there a more efficient way of doing this ? Copying only part of the
content is worse (i've tried). 2) Can I prevent the content of the table from spilling over the table to right of the left ? I get the same behaviour in a GOP, and putting a canvas next to the table to cover it doesn't work because the table content gets redrawn on top of it.
This leads me to a more general question about something i've found in the help : "5 Wave editing: with proper manipulation of array data, Pd can be fully functional wave editor, complete with mouse-clickable cut-n-paste, pitch-shift, time expansion, down/upsampling, and other tools typically found in commercial wave editors." This has always sounded very appealing to me, but i wonder how realistic this statement is... unless i'm ignoring 80 % of what can be done with tables in Pd.
Cheers,
Pierre.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
seems like there was something about the way i made the wave editor that worked,i never tried overflowing the the things and my method is a hack of the pd file @xensynth and the lfo editor, otherwise holler at Mike Booth ala mmb.
https://archive.org/search.php?query=uploader%3A%22billy.stiltner%40gmail.co...
On Mon, Mar 3, 2014 at 2:34 AM, Pierre Massat pimassat@gmail.com wrote:
Hi Jonathan,
I found it following this path : help for [tabwrite] --> More_Info --> all_about_arrays --> Common uses for arrays in Pd Bummer, I thought somebody would come up with a secret table manipulation technique that would make this statement true...
Cheers,
Pierre.
2014-03-02 19:33 GMT+01:00 Jonathan Wilkes jancsika@yahoo.com:
From that help patch:
#X text 12 115 HELP_PATCH_AUTHORS Updated for Pd 0.38-2. Jonathan Wilkes revised the patch to conform to the PDDP template for Pd version 0.42.
I did the refactoring of that patch, but I'm not sure who wrote what you're quoting.
I'd say that statement is false and should be removed.
-Jonathan
On Sunday, March 2, 2014 10:47 AM, Pierre Massat pimassat@gmail.com wrote: Dear list,
I am working on a small patch which stores simple events in a table to trigger sounds later on. I would like to be able to edit the content of my table easily, which requires scrolling it, zooming in, and eventually editing the content.
I have found away of scrolling the content, but it is very slow with relatively big tables (hem, even with a table with 20 000 samples...). Please see the example attached.
I have 2 questions :
- Is there a more efficient way of doing this ? Copying only part of the
content is worse (i've tried). 2) Can I prevent the content of the table from spilling over the table to right of the left ? I get the same behaviour in a GOP, and putting a canvas next to the table to cover it doesn't work because the table content gets redrawn on top of it.
This leads me to a more general question about something i've found in the help : "5 Wave editing: with proper manipulation of array data, Pd can be fully functional wave editor, complete with mouse-clickable cut-n-paste, pitch-shift, time expansion, down/upsampling, and other tools typically found in commercial wave editors." This has always sounded very appealing to me, but i wonder how realistic this statement is... unless i'm ignoring 80 % of what can be done with tables in Pd.
Cheers,
Pierre.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I've looked seriously at data structures for the first time, and saw what Chris McCormick did with them, and I believe this is the way to go !
Cheers,
Pierre.
2014-03-03 8:44 GMT+01:00 Billy Stiltner billy.stiltner@gmail.com:
seems like there was something about the way i made the wave editor that worked,i never tried overflowing the the things and my method is a hack of the pd file @xensynth and the lfo editor, otherwise holler at Mike Booth ala mmb.
https://archive.org/search.php?query=uploader%3A%22billy.stiltner%40gmail.co...
On Mon, Mar 3, 2014 at 2:34 AM, Pierre Massat pimassat@gmail.com wrote:
Hi Jonathan,
I found it following this path : help for [tabwrite] --> More_Info --> all_about_arrays --> Common uses for arrays in Pd Bummer, I thought somebody would come up with a secret table manipulation technique that would make this statement true...
Cheers,
Pierre.
2014-03-02 19:33 GMT+01:00 Jonathan Wilkes jancsika@yahoo.com:
From that help patch:
#X text 12 115 HELP_PATCH_AUTHORS Updated for Pd 0.38-2. Jonathan Wilkes revised the patch to conform to the PDDP template for Pd version 0.42.
I did the refactoring of that patch, but I'm not sure who wrote what you're quoting.
I'd say that statement is false and should be removed.
-Jonathan
On Sunday, March 2, 2014 10:47 AM, Pierre Massat pimassat@gmail.com wrote: Dear list,
I am working on a small patch which stores simple events in a table to trigger sounds later on. I would like to be able to edit the content of my table easily, which requires scrolling it, zooming in, and eventually editing the content.
I have found away of scrolling the content, but it is very slow with relatively big tables (hem, even with a table with 20 000 samples...). Please see the example attached.
I have 2 questions :
- Is there a more efficient way of doing this ? Copying only part of
the content is worse (i've tried). 2) Can I prevent the content of the table from spilling over the table to right of the left ? I get the same behaviour in a GOP, and putting a canvas next to the table to cover it doesn't work because the table content gets redrawn on top of it.
This leads me to a more general question about something i've found in the help : "5 Wave editing: with proper manipulation of array data, Pd can be fully functional wave editor, complete with mouse-clickable cut-n-paste, pitch-shift, time expansion, down/upsampling, and other tools typically found in commercial wave editors." This has always sounded very appealing to me, but i wonder how realistic this statement is... unless i'm ignoring 80 % of what can be done with tables in Pd.
Cheers,
Pierre.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 03/03/2014 01:32 PM, Pierre Massat wrote:
I've looked seriously at data structures for the first time, and saw what Chris McCormick did with them, and I believe this is the way to go !
But you can't get notifications for mouseover or right-click events.
You also cannot get transparency or control the z-order among multiple
scalars. Nor scale or zoom without creating another complex and slow
wrapper on top of data structures.
Don't get me wrong-- you can do interesting things with scalars, and you can build a wave-editor that looks quite advanced compared to what a GUI in Pd typically looks like. But you cannot get anything that looks remotely like a modern or even decade-old commercial wave-editor.
So I'd rather the documentation didn't send people searching around the corners of the software for features that don't exist.
-Jonathan
Cheers,
Pierre.
2014-03-03 8:44 GMT+01:00 Billy Stiltner <billy.stiltner@gmail.com mailto:billy.stiltner@gmail.com>:
seems like there was something about the way i made the wave editor that worked,i never tried overflowing the the things and my method is a hack of the pd file @xensynth and the lfo editor, otherwise holler at Mike Booth ala mmb. https://archive.org/search.php?query=uploader%3A%22billy.stiltner%40gmail.com%22&sort=-publicdate On Mon, Mar 3, 2014 at 2:34 AM, Pierre Massat <pimassat@gmail.com <mailto:pimassat@gmail.com>> wrote: Hi Jonathan, I found it following this path : help for [tabwrite] --> More_Info --> all_about_arrays --> Common uses for arrays in Pd Bummer, I thought somebody would come up with a secret table manipulation technique that would make this statement true... Cheers, Pierre. 2014-03-02 19:33 GMT+01:00 Jonathan Wilkes <jancsika@yahoo.com <mailto:jancsika@yahoo.com>>: From that help patch: #X text 12 115 HELP_PATCH_AUTHORS Updated for Pd 0.38-2. Jonathan Wilkes revised the patch to conform to the PDDP template for Pd version 0.42. I did the refactoring of that patch, but I'm not sure who wrote what you're quoting. I'd say that statement is false and should be removed. -Jonathan On Sunday, March 2, 2014 10:47 AM, Pierre Massat <pimassat@gmail.com <mailto:pimassat@gmail.com>> wrote: Dear list, I am working on a small patch which stores simple events in a table to trigger sounds later on. I would like to be able to edit the content of my table easily, which requires scrolling it, zooming in, and eventually editing the content. I have found away of scrolling the content, but it is very slow with relatively big tables (hem, even with a table with 20 000 samples...). Please see the example attached. I have 2 questions : 1) Is there a more efficient way of doing this ? Copying only part of the content is worse (i've tried). 2) Can I prevent the content of the table from spilling over the table to right of the left ? I get the same behaviour in a GOP, and putting a canvas next to the table to cover it doesn't work because the table content gets redrawn on top of it. This leads me to a more general question about something i've found in the help : "5 Wave editing: with proper manipulation of array data, Pd can be fully functional wave editor, complete with mouse-clickable cut-n-paste, pitch-shift, time expansion, down/upsampling, and other tools typically found in commercial wave editors." This has always sounded very appealing to me, but i wonder how realistic this statement is... unless i'm ignoring 80 % of what can be done with tables in Pd. Cheers, Pierre. _______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
just for interest perhaps, here's the sound editor i made years ago:
http://puredata.hurleur.com/sujet-1295-sound-editor
and probably even more interesting, here is maelstorm's wave display abstraction:
http://puredata.hurleur.com/sujet-5890-waveform-display
basically, what maelstorm discovered was that using [until] with a counter was not nearly fast enough to do the calculations needed for a decent zoom/scroll function, and we looked into it, and there just didn't seem to be a vanilla workaround. So he uses iem_tab objects to do the table calculations.
On Tue, Mar 4, 2014 at 7:26 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
On 03/03/2014 01:32 PM, Pierre Massat wrote:
I've looked seriously at data structures for the first time, and saw what Chris McCormick did with them, and I believe this is the way to go !
But you can't get notifications for mouseover or right-click events. You also cannot get transparency or control the z-order among multiple scalars. Nor scale or zoom without creating another complex and slow wrapper on top of data structures.
Don't get me wrong-- you can do interesting things with scalars, and you can build a wave-editor that looks quite advanced compared to what a GUI in Pd typically looks like. But you cannot get anything that looks remotely like a modern or even decade-old commercial wave-editor.
So I'd rather the documentation didn't send people searching around the corners of the software for features that don't exist.
-Jonathan
Cheers,
Pierre.
2014-03-03 8:44 GMT+01:00 Billy Stiltner billy.stiltner@gmail.com:
seems like there was something about the way i made the wave editor that worked,i never tried overflowing the the things and my method is a hack of the pd file @xensynth and the lfo editor, otherwise holler at Mike Booth ala mmb.
https://archive.org/search.php?query=uploader%3A%22billy.stiltner%40gmail.co...
On Mon, Mar 3, 2014 at 2:34 AM, Pierre Massat pimassat@gmail.com wrote:
Hi Jonathan,
I found it following this path : help for [tabwrite] --> More_Info --> all_about_arrays --> Common uses for arrays in Pd Bummer, I thought somebody would come up with a secret table manipulation technique that would make this statement true...
Cheers,
Pierre.
2014-03-02 19:33 GMT+01:00 Jonathan Wilkes jancsika@yahoo.com:
From that help patch:
#X text 12 115 HELP_PATCH_AUTHORS Updated for Pd 0.38-2. Jonathan Wilkes revised the patch to conform to the PDDP template for Pd version 0.42.
I did the refactoring of that patch, but I'm not sure who wrote what you're quoting.
I'd say that statement is false and should be removed.
-Jonathan
On Sunday, March 2, 2014 10:47 AM, Pierre Massat pimassat@gmail.com wrote: Dear list,
I am working on a small patch which stores simple events in a table to trigger sounds later on. I would like to be able to edit the content of my table easily, which requires scrolling it, zooming in, and eventually editing the content.
I have found away of scrolling the content, but it is very slow with relatively big tables (hem, even with a table with 20 000 samples...). Please see the example attached.
I have 2 questions :
- Is there a more efficient way of doing this ? Copying only part of
the content is worse (i've tried). 2) Can I prevent the content of the table from spilling over the table to right of the left ? I get the same behaviour in a GOP, and putting a canvas next to the table to cover it doesn't work because the table content gets redrawn on top of it.
This leads me to a more general question about something i've found in the help : "5 Wave editing: with proper manipulation of array data, Pd can be fully functional wave editor, complete with mouse-clickable cut-n-paste, pitch-shift, time expansion, down/upsampling, and other tools typically found in commercial wave editors." This has always sounded very appealing to me, but i wonder how realistic this statement is... unless i'm ignoring 80 % of what can be done with tables in Pd.
Cheers,
Pierre.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Wow, your patch is impressive, i'd missed that. I've looked at maelstrom's editor as well. Both will be nice things to study. i think i'll stick to data structures though because what i need is something to record and edit discrete events, not an audio signal. I don't think i have to use tables at all finally.
2014-03-04 12:12 GMT+01:00 i go bananas hard.off@gmail.com:
just for interest perhaps, here's the sound editor i made years ago:
http://puredata.hurleur.com/sujet-1295-sound-editor
and probably even more interesting, here is maelstorm's wave display abstraction:
http://puredata.hurleur.com/sujet-5890-waveform-display
basically, what maelstorm discovered was that using [until] with a counter was not nearly fast enough to do the calculations needed for a decent zoom/scroll function, and we looked into it, and there just didn't seem to be a vanilla workaround. So he uses iem_tab objects to do the table calculations.
On Tue, Mar 4, 2014 at 7:26 AM, Jonathan Wilkes jancsika@yahoo.comwrote:
On 03/03/2014 01:32 PM, Pierre Massat wrote:
I've looked seriously at data structures for the first time, and saw what Chris McCormick did with them, and I believe this is the way to go !
But you can't get notifications for mouseover or right-click events. You also cannot get transparency or control the z-order among multiple scalars. Nor scale or zoom without creating another complex and slow wrapper on top of data structures.
Don't get me wrong-- you can do interesting things with scalars, and you can build a wave-editor that looks quite advanced compared to what a GUI in Pd typically looks like. But you cannot get anything that looks remotely like a modern or even decade-old commercial wave-editor.
So I'd rather the documentation didn't send people searching around the corners of the software for features that don't exist.
-Jonathan
Cheers,
Pierre.
2014-03-03 8:44 GMT+01:00 Billy Stiltner billy.stiltner@gmail.com:
seems like there was something about the way i made the wave editor that worked,i never tried overflowing the the things and my method is a hack of the pd file @xensynth and the lfo editor, otherwise holler at Mike Booth ala mmb.
https://archive.org/search.php?query=uploader%3A%22billy.stiltner%40gmail.co...
On Mon, Mar 3, 2014 at 2:34 AM, Pierre Massat pimassat@gmail.comwrote:
Hi Jonathan,
I found it following this path : help for [tabwrite] --> More_Info --> all_about_arrays --> Common uses for arrays in Pd Bummer, I thought somebody would come up with a secret table manipulation technique that would make this statement true...
Cheers,
Pierre.
2014-03-02 19:33 GMT+01:00 Jonathan Wilkes jancsika@yahoo.com:
From that help patch:
#X text 12 115 HELP_PATCH_AUTHORS Updated for Pd 0.38-2. Jonathan Wilkes revised the patch to conform to the PDDP template for Pd version 0.42.
I did the refactoring of that patch, but I'm not sure who wrote what you're quoting.
I'd say that statement is false and should be removed.
-Jonathan
On Sunday, March 2, 2014 10:47 AM, Pierre Massat < pimassat@gmail.com> wrote: Dear list,
I am working on a small patch which stores simple events in a table to trigger sounds later on. I would like to be able to edit the content of my table easily, which requires scrolling it, zooming in, and eventually editing the content.
I have found away of scrolling the content, but it is very slow with relatively big tables (hem, even with a table with 20 000 samples...). Please see the example attached.
I have 2 questions :
- Is there a more efficient way of doing this ? Copying only part of
the content is worse (i've tried). 2) Can I prevent the content of the table from spilling over the table to right of the left ? I get the same behaviour in a GOP, and putting a canvas next to the table to cover it doesn't work because the table content gets redrawn on top of it.
This leads me to a more general question about something i've found in the help : "5 Wave editing: with proper manipulation of array data, Pd can be fully functional wave editor, complete with mouse-clickable cut-n-paste, pitch-shift, time expansion, down/upsampling, and other tools typically found in commercial wave editors." This has always sounded very appealing to me, but i wonder how realistic this statement is... unless i'm ignoring 80 % of what can be done with tables in Pd.
Cheers,
Pierre.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
from memory, i THINK maelstorm's wave display DOES use data structures to do the display.
On Tue, Mar 4, 2014 at 10:28 PM, Pierre Massat pimassat@gmail.com wrote:
Wow, your patch is impressive, i'd missed that. I've looked at maelstrom's editor as well. Both will be nice things to study. i think i'll stick to data structures though because what i need is something to record and edit discrete events, not an audio signal. I don't think i have to use tables at all finally.
2014-03-04 12:12 GMT+01:00 i go bananas hard.off@gmail.com:
just for interest perhaps, here's the sound editor i made years ago:
http://puredata.hurleur.com/sujet-1295-sound-editor
and probably even more interesting, here is maelstorm's wave display abstraction:
http://puredata.hurleur.com/sujet-5890-waveform-display
basically, what maelstorm discovered was that using [until] with a counter was not nearly fast enough to do the calculations needed for a decent zoom/scroll function, and we looked into it, and there just didn't seem to be a vanilla workaround. So he uses iem_tab objects to do the table calculations.
On Tue, Mar 4, 2014 at 7:26 AM, Jonathan Wilkes jancsika@yahoo.comwrote:
On 03/03/2014 01:32 PM, Pierre Massat wrote:
I've looked seriously at data structures for the first time, and saw what Chris McCormick did with them, and I believe this is the way to go !
But you can't get notifications for mouseover or right-click events. You also cannot get transparency or control the z-order among multiple scalars. Nor scale or zoom without creating another complex and slow wrapper on top of data structures.
Don't get me wrong-- you can do interesting things with scalars, and you can build a wave-editor that looks quite advanced compared to what a GUI in Pd typically looks like. But you cannot get anything that looks remotely like a modern or even decade-old commercial wave-editor.
So I'd rather the documentation didn't send people searching around the corners of the software for features that don't exist.
-Jonathan
Cheers,
Pierre.
2014-03-03 8:44 GMT+01:00 Billy Stiltner billy.stiltner@gmail.com:
seems like there was something about the way i made the wave editor that worked,i never tried overflowing the the things and my method is a hack of the pd file @xensynth and the lfo editor, otherwise holler at Mike Booth ala mmb.
https://archive.org/search.php?query=uploader%3A%22billy.stiltner%40gmail.co...
On Mon, Mar 3, 2014 at 2:34 AM, Pierre Massat pimassat@gmail.comwrote:
Hi Jonathan,
I found it following this path : help for [tabwrite] --> More_Info --> all_about_arrays --> Common uses for arrays in Pd Bummer, I thought somebody would come up with a secret table manipulation technique that would make this statement true...
Cheers,
Pierre.
2014-03-02 19:33 GMT+01:00 Jonathan Wilkes jancsika@yahoo.com:
From that help patch:
#X text 12 115 HELP_PATCH_AUTHORS Updated for Pd 0.38-2. Jonathan Wilkes revised the patch to conform to the PDDP template for Pd version 0.42.
I did the refactoring of that patch, but I'm not sure who wrote what you're quoting.
I'd say that statement is false and should be removed.
-Jonathan
On Sunday, March 2, 2014 10:47 AM, Pierre Massat < pimassat@gmail.com> wrote: Dear list,
I am working on a small patch which stores simple events in a table to trigger sounds later on. I would like to be able to edit the content of my table easily, which requires scrolling it, zooming in, and eventually editing the content.
I have found away of scrolling the content, but it is very slow with relatively big tables (hem, even with a table with 20 000 samples...). Please see the example attached.
I have 2 questions :
- Is there a more efficient way of doing this ? Copying only part
of the content is worse (i've tried). 2) Can I prevent the content of the table from spilling over the table to right of the left ? I get the same behaviour in a GOP, and putting a canvas next to the table to cover it doesn't work because the table content gets redrawn on top of it.
This leads me to a more general question about something i've found in the help : "5 Wave editing: with proper manipulation of array data, Pd can be fully functional wave editor, complete with mouse-clickable cut-n-paste, pitch-shift, time expansion, down/upsampling, and other tools typically found in commercial wave editors." This has always sounded very appealing to me, but i wonder how realistic this statement is... unless i'm ignoring 80 % of what can be done with tables in Pd.
Cheers,
Pierre.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 03/04/2014 10:11 AM, i go bananas wrote:
[...]
2014-03-04 12:12 GMT+01:00 i go bananas <hard.off@gmail.com <mailto:hard.off@gmail.com>>: just for interest perhaps, here's the sound editor i made years ago: http://puredata.hurleur.com/sujet-1295-sound-editor and probably even more interesting, here is maelstorm's wave display abstraction: http://puredata.hurleur.com/sujet-5890-waveform-display basically, what maelstorm discovered was that using [until] with a counter was not nearly fast enough to do the calculations needed for a decent zoom/scroll function, and we looked into it, and there just didn't seem to be a vanilla workaround. So he uses iem_tab objects to do the table calculations.
Remember that when you redraw an element of an array you actually redraw the _entire_ array in Pd Vanilla. And depending on the array style you may have a separate tk canvas item for each element.
So when you use the [until] loop you are sending drawing instructions to the GUI ($arraysize * $no_mouse_events) times. A single array redraw instruction in tcl is about 4k, so to scroll a single pixel for a 100-element array: 100 elements * 1 = 100 redraws * 4k = 400k
That's flowing from the core to the GUI for a _single_ mouse event. If you trigger ten scrolls you're already at 4 megs of data sent.
I'm pretty sure commercial editors avoid that type of design. In editors like the upcoming Openshot Video that have several discrete parts that sending messages, the GUI part almost certainly sends nothing at all to the video core for zooming/scrolling. For moving a chunk of audio/video, it almost certainly sends a single message about a single object's delta.
-Jonathan
On 03/04/2014 01:20 PM, Jonathan Wilkes wrote:
On 03/04/2014 10:11 AM, i go bananas wrote:
[...]
2014-03-04 12:12 GMT+01:00 i go bananas <hard.off@gmail.com <mailto:hard.off@gmail.com>>: just for interest perhaps, here's the sound editor i made years ago: http://puredata.hurleur.com/sujet-1295-sound-editor and probably even more interesting, here is maelstorm's wave display abstraction: http://puredata.hurleur.com/sujet-5890-waveform-display basically, what maelstorm discovered was that using [until] with a counter was not nearly fast enough to do the calculations needed for a decent zoom/scroll function, and we looked into it, and there just didn't seem to be a vanilla workaround. So he uses iem_tab objects to do the table calculations.Remember that when you redraw an element of an array you actually redraw the _entire_ array in Pd Vanilla. And depending on the array style you may have a separate tk canvas item for each element.
So when you use the [until] loop you are sending drawing instructions to the GUI ($arraysize * $no_mouse_events) times. A single array redraw instruction in tcl is about 4k, so to scroll a single pixel for a 100-element array: 100 elements * 1 = 100 redraws * 4k = 400k
That's flowing from the core to the GUI for a _single_ mouse event.
If you trigger ten scrolls you're already at 4 megs of data sent.I'm pretty sure commercial editors avoid that type of design. In editors like the upcoming Openshot Video that have several discrete parts that sending messages, the GUI part almost certainly sends nothing at all to the video core for zooming/scrolling. For moving a chunk of audio/video, it almost certainly sends a single message about a single object's delta.
I may have showed this already, but I think it's instructive here: https://jwilkes.nfshost.com/pd-tiger.webm
I don't have sound on that clip, but I believe I tried it with the "test audio" patch going and I wasn't getting dropouts. This is because a) I'm sending a single transform message for every scroll of the number box and b) the GUI toolkit-- not Pd core-- is doing the math to transform and redisplay the drawing.
Socket traffic is bad because it require both the core (sending) and GUI (receiving) to do work. If you generate megs and megs of traffic you can end up with dropouts and choking display even if there's very little being redrawn.
-Jonathan
-Jonathan
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
"So when you use the [until] loop you are sending drawing instructions to the GUI ($arraysize * $no_mouse_events) times. A single array redraw instruction in tcl is about 4k, so to scroll a single pixel for a 100-element array: 100 elements * 1 = 100 redraws * 4k = 400k"
thats why i say fix tcl/tk my old graphics library could be used for a new gui. it is c++ but has the logic to even only update lines as in blit an arbitrary line.
On Tue, Mar 4, 2014 at 1:33 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
On 03/04/2014 01:20 PM, Jonathan Wilkes wrote:
On 03/04/2014 10:11 AM, i go bananas wrote:
[...]
2014-03-04 12:12 GMT+01:00 i go bananas hard.off@gmail.com:
just for interest perhaps, here's the sound editor i made years ago:
http://puredata.hurleur.com/sujet-1295-sound-editor
and probably even more interesting, here is maelstorm's wave display abstraction:
http://puredata.hurleur.com/sujet-5890-waveform-display
basically, what maelstorm discovered was that using [until] with a counter was not nearly fast enough to do the calculations needed for a decent zoom/scroll function, and we looked into it, and there just didn't seem to be a vanilla workaround. So he uses iem_tab objects to do the table calculations.
Remember that when you redraw an element of an array you actually redraw the _entire_ array in Pd Vanilla. And depending on the array style you may have a separate tk canvas item for each element.
So when you use the [until] loop you are sending drawing instructions to the GUI ($arraysize * $no_mouse_events) times. A single array redraw instruction in tcl is about 4k, so to scroll a single pixel for a 100-element array: 100 elements * 1 = 100 redraws * 4k = 400k
That's flowing from the core to the GUI for a _single_ mouse event. If you trigger ten scrolls you're already at 4 megs of data sent.
I'm pretty sure commercial editors avoid that type of design. In editors like the upcoming Openshot Video that have several discrete parts that sending messages, the GUI part almost certainly sends nothing at all to the video core for zooming/scrolling. For moving a chunk of audio/video, it almost certainly sends a single message about a single object's delta.
I may have showed this already, but I think it's instructive here: https://jwilkes.nfshost.com/pd-tiger.webm
I don't have sound on that clip, but I believe I tried it with the "test audio" patch going and I wasn't getting dropouts. This is because a) I'm sending a single transform message for every scroll of the number box and b) the GUI toolkit-- not Pd core-- is doing the math to transform and redisplay the drawing.
Socket traffic is bad because it require both the core (sending) and GUI (receiving) to do work. If you generate megs and megs of traffic you can end up with dropouts and choking display even if there's very little being redrawn.
-Jonathan
-Jonathan
_______________________________________________Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Remember that when you redraw an element of an array you actually redraw
the _entire_ array in Pd Vanilla. And depending on the array style you may have a separate tk canvas item for each element.<<
why do the iem tab objects work so much better then? maelstorm said that it was incredibly slow using an [until] based counter, but worked smoothly with the iem objects. This was for EXACTLY the same gui, so i'm not really sure if it's a gui redraw issue.
Then again, he also said that the iem tabs objects seem to process tables in chunks...so maybe the gui is also only redrawn in those chunk sizes? that would make sense i guess.
On Wed, Mar 5, 2014 at 10:35 AM, Billy Stiltner billy.stiltner@gmail.comwrote:
"So when you use the [until] loop you are sending drawing instructions to the GUI ($arraysize * $no_mouse_events) times. A single array redraw instruction in tcl is about 4k, so to scroll a single pixel for a 100-element array: 100 elements * 1 = 100 redraws * 4k = 400k"
thats why i say fix tcl/tk my old graphics library could be used for a new gui. it is c++ but has the logic to even only update lines as in blit an arbitrary line.
On Tue, Mar 4, 2014 at 1:33 PM, Jonathan Wilkes jancsika@yahoo.comwrote:
On 03/04/2014 01:20 PM, Jonathan Wilkes wrote:
On 03/04/2014 10:11 AM, i go bananas wrote:
[...]
2014-03-04 12:12 GMT+01:00 i go bananas hard.off@gmail.com:
just for interest perhaps, here's the sound editor i made years ago:
http://puredata.hurleur.com/sujet-1295-sound-editor
and probably even more interesting, here is maelstorm's wave display abstraction:
http://puredata.hurleur.com/sujet-5890-waveform-display
basically, what maelstorm discovered was that using [until] with a counter was not nearly fast enough to do the calculations needed for a decent zoom/scroll function, and we looked into it, and there just didn't seem to be a vanilla workaround. So he uses iem_tab objects to do the table calculations.
Remember that when you redraw an element of an array you actually redraw the _entire_ array in Pd Vanilla. And depending on the array style you may have a separate tk canvas item for each element.
So when you use the [until] loop you are sending drawing instructions to the GUI ($arraysize * $no_mouse_events) times. A single array redraw instruction in tcl is about 4k, so to scroll a single pixel for a 100-element array: 100 elements * 1 = 100 redraws * 4k = 400k
That's flowing from the core to the GUI for a _single_ mouse event. If you trigger ten scrolls you're already at 4 megs of data sent.
I'm pretty sure commercial editors avoid that type of design. In editors like the upcoming Openshot Video that have several discrete parts that sending messages, the GUI part almost certainly sends nothing at all to the video core for zooming/scrolling. For moving a chunk of audio/video, it almost certainly sends a single message about a single object's delta.
I may have showed this already, but I think it's instructive here: https://jwilkes.nfshost.com/pd-tiger.webm
I don't have sound on that clip, but I believe I tried it with the "test audio" patch going and I wasn't getting dropouts. This is because a) I'm sending a single transform message for every scroll of the number box and b) the GUI toolkit-- not Pd core-- is doing the math to transform and redisplay the drawing.
Socket traffic is bad because it require both the core (sending) and GUI (receiving) to do work. If you generate megs and megs of traffic you can end up with dropouts and choking display even if there's very little being redrawn.
-Jonathan
-Jonathan
_______________________________________________Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
i will look into it next week after my social escapades
On Wed, Mar 5, 2014 at 4:36 AM, i go bananas hard.off@gmail.com wrote:
Remember that when you redraw an element of an array you actually
redraw the _entire_ array in Pd Vanilla. And depending on the array style you may have a separate tk canvas item for each element.<<
why do the iem tab objects work so much better then? maelstorm said that it was incredibly slow using an [until] based counter, but worked smoothly with the iem objects. This was for EXACTLY the same gui, so i'm not really sure if it's a gui redraw issue.
Then again, he also said that the iem tabs objects seem to process tables in chunks...so maybe the gui is also only redrawn in those chunk sizes? that would make sense i guess.
On Wed, Mar 5, 2014 at 10:35 AM, Billy Stiltner billy.stiltner@gmail.comwrote:
"So when you use the [until] loop you are sending drawing instructions to the GUI ($arraysize * $no_mouse_events) times. A single array redraw instruction in tcl is about 4k, so to scroll a single pixel for a 100-element array: 100 elements * 1 = 100 redraws * 4k = 400k"
thats why i say fix tcl/tk my old graphics library could be used for a new gui. it is c++ but has the logic to even only update lines as in blit an arbitrary line.
On Tue, Mar 4, 2014 at 1:33 PM, Jonathan Wilkes jancsika@yahoo.comwrote:
On 03/04/2014 01:20 PM, Jonathan Wilkes wrote:
On 03/04/2014 10:11 AM, i go bananas wrote:
[...]
2014-03-04 12:12 GMT+01:00 i go bananas hard.off@gmail.com:
just for interest perhaps, here's the sound editor i made years ago:
http://puredata.hurleur.com/sujet-1295-sound-editor
and probably even more interesting, here is maelstorm's wave display abstraction:
http://puredata.hurleur.com/sujet-5890-waveform-display
basically, what maelstorm discovered was that using [until] with a counter was not nearly fast enough to do the calculations needed for a decent zoom/scroll function, and we looked into it, and there just didn't seem to be a vanilla workaround. So he uses iem_tab objects to do the table calculations.
Remember that when you redraw an element of an array you actually redraw the _entire_ array in Pd Vanilla. And depending on the array style you may have a separate tk canvas item for each element.
So when you use the [until] loop you are sending drawing instructions to the GUI ($arraysize * $no_mouse_events) times. A single array redraw instruction in tcl is about 4k, so to scroll a single pixel for a 100-element array: 100 elements * 1 = 100 redraws * 4k = 400k
That's flowing from the core to the GUI for a _single_ mouse event. If you trigger ten scrolls you're already at 4 megs of data sent.
I'm pretty sure commercial editors avoid that type of design. In editors like the upcoming Openshot Video that have several discrete parts that sending messages, the GUI part almost certainly sends nothing at all to the video core for zooming/scrolling. For moving a chunk of audio/video, it almost certainly sends a single message about a single object's delta.
I may have showed this already, but I think it's instructive here: https://jwilkes.nfshost.com/pd-tiger.webm
I don't have sound on that clip, but I believe I tried it with the "test audio" patch going and I wasn't getting dropouts. This is because a) I'm sending a single transform message for every scroll of the number box and b) the GUI toolkit-- not Pd core-- is doing the math to transform and redisplay the drawing.
Socket traffic is bad because it require both the core (sending) and GUI (receiving) to do work. If you generate megs and megs of traffic you can end up with dropouts and choking display even if there's very little being redrawn.
-Jonathan
-Jonathan
_______________________________________________Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 03/05/2014 04:36 AM, i go bananas wrote:
Remember that when you redraw an element of an array you actually
redraw the _entire_ array in Pd Vanilla. And depending on the array style you may have a separate tk canvas item for each element.<<
why do the iem tab objects work so much better then?
I haven't looked at the code, but I'd imagine those externals do some
array-wide operation then trigger a single redraw of the entire array.
For a 100-element array that'd be 100x faster.
But if you want the GUI to look modern you want the chunk of samples you're displacing to redraw ASAP. For that Pd (Vanilla) still needs to continually delete and redraw the array as you click-drag the selection. So it's better than the worst of all possible worlds-- using [tabwrite]-- but still extremely inefficient (not to mention it doesn't scale).
To be fair, it's unclear how to "do this right" even with a "clean" separation of GUI/core. It's unclear what "clean" means, and it's unclear what "this" is.
To be specific: it's really hard to predict what purpose the user will find for the realtime audio engine when the GUI is also a programming language. For example, you can get all kinds of speedups in a DAW by waiting for the user to release the mouse button when displacing a selection. But if you did that by default for "Put" menu arrays you'd ruin several of Miller's tutorials, where an immediate connection between visual array change and audio change is vital if inefficient.
-Jonathan
maelstorm said that it was incredibly slow using an [until] based counter, but worked smoothly with the iem objects. This was for EXACTLY the same gui, so i'm not really sure if it's a gui redraw issue.
Then again, he also said that the iem tabs objects seem to process tables in chunks...so maybe the gui is also only redrawn in those chunk sizes? that would make sense i guess.
On Wed, Mar 5, 2014 at 10:35 AM, Billy Stiltner <billy.stiltner@gmail.com mailto:billy.stiltner@gmail.com> wrote:
"So when you use the [until] loop you are sending drawing instructions to the GUI ($arraysize * $no_mouse_events) times. A single array redraw instruction in tcl is about 4k, so to scroll a single pixel for a 100-element array: 100 elements * 1 = 100 redraws * 4k = 400k" thats why i say fix tcl/tk my old graphics library could be used for a new gui. it is c++ but has the logic to even only update lines as in blit an arbitrary line. On Tue, Mar 4, 2014 at 1:33 PM, Jonathan Wilkes <jancsika@yahoo.com <mailto:jancsika@yahoo.com>> wrote: On 03/04/2014 01:20 PM, Jonathan Wilkes wrote:On 03/04/2014 10:11 AM, i go bananas wrote: [...]2014-03-04 12:12 GMT+01:00 i go bananas <hard.off@gmail.com <mailto:hard.off@gmail.com>>: just for interest perhaps, here's the sound editor i made years ago: http://puredata.hurleur.com/sujet-1295-sound-editor and probably even more interesting, here is maelstorm's wave display abstraction: http://puredata.hurleur.com/sujet-5890-waveform-display basically, what maelstorm discovered was that using [until] with a counter was not nearly fast enough to do the calculations needed for a decent zoom/scroll function, and we looked into it, and there just didn't seem to be a vanilla workaround. So he uses iem_tab objects to do the table calculations.Remember that when you redraw an element of an array you actually redraw the _entire_ array in Pd Vanilla. And depending on the array style you may have a separate tk canvas item for each element. So when you use the [until] loop you are sending drawing instructions to the GUI ($arraysize * $no_mouse_events) times. A single array redraw instruction in tcl is about 4k, so to scroll a single pixel for a 100-element array: 100 elements * 1 = 100 redraws * 4k = 400k That's flowing from the core to the GUI for a _single_ mouse event. If you trigger ten scrolls you're already at 4 megs of data sent. I'm pretty sure commercial editors avoid that type of design. In editors like the upcoming Openshot Video that have several discrete parts that sending messages, the GUI part almost certainly sends nothing at all to the video core for zooming/scrolling. For moving a chunk of audio/video, it almost certainly sends a single message about a single object's delta.I may have showed this already, but I think it's instructive here: https://jwilkes.nfshost.com/pd-tiger.webm I don't have sound on that clip, but I believe I tried it with the "test audio" patch going and I wasn't getting dropouts. This is because a) I'm sending a single transform message for every scroll of the number box and b) the GUI toolkit-- not Pd core-- is doing the math to transform and redisplay the drawing. Socket traffic is bad because it require both the core (sending) and GUI (receiving) to do work. If you generate megs and megs of traffic you can end up with dropouts and choking display even if there's very little being redrawn. -Jonathan-Jonathan _______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list UNSUBSCRIBE and account-management ->http://lists.puredata.info/listinfo/pd-list_______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 03/03/2014 02:44 AM, Billy Stiltner wrote:
seems like there was something about the way i made the wave editor that worked,i never tried overflowing the the things and my method is a hack of the pd file @xensynth and the lfo editor, otherwise holler at Mike Booth ala mmb.
You can make a wave editor. You just cannot make a wave editor that has the tools typically found in commercial wave editors, unless you systematically ignore the modern/sophisticated GUI systems which make commercial wave editors efficient to use.
-Jonahan
https://archive.org/search.php?query=uploader%3A%22billy.stiltner%40gmail.co...
On Mon, Mar 3, 2014 at 2:34 AM, Pierre Massat <pimassat@gmail.com mailto:pimassat@gmail.com> wrote:
Hi Jonathan, I found it following this path : help for [tabwrite] --> More_Info --> all_about_arrays --> Common uses for arrays in Pd Bummer, I thought somebody would come up with a secret table manipulation technique that would make this statement true... Cheers, Pierre. 2014-03-02 19:33 GMT+01:00 Jonathan Wilkes <jancsika@yahoo.com <mailto:jancsika@yahoo.com>>: From that help patch: #X text 12 115 HELP_PATCH_AUTHORS Updated for Pd 0.38-2. Jonathan Wilkes revised the patch to conform to the PDDP template for Pd version 0.42. I did the refactoring of that patch, but I'm not sure who wrote what you're quoting. I'd say that statement is false and should be removed. -Jonathan On Sunday, March 2, 2014 10:47 AM, Pierre Massat <pimassat@gmail.com <mailto:pimassat@gmail.com>> wrote: Dear list, I am working on a small patch which stores simple events in a table to trigger sounds later on. I would like to be able to edit the content of my table easily, which requires scrolling it, zooming in, and eventually editing the content. I have found away of scrolling the content, but it is very slow with relatively big tables (hem, even with a table with 20 000 samples...). Please see the example attached. I have 2 questions : 1) Is there a more efficient way of doing this ? Copying only part of the content is worse (i've tried). 2) Can I prevent the content of the table from spilling over the table to right of the left ? I get the same behaviour in a GOP, and putting a canvas next to the table to cover it doesn't work because the table content gets redrawn on top of it. This leads me to a more general question about something i've found in the help : "5 Wave editing: with proper manipulation of array data, Pd can be fully functional wave editor, complete with mouse-clickable cut-n-paste, pitch-shift, time expansion, down/upsampling, and other tools typically found in commercial wave editors." This has always sounded very appealing to me, but i wonder how realistic this statement is... unless i'm ignoring 80 % of what can be done with tables in Pd. Cheers, Pierre. _______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Billy Stiltner -
i go bananas -
Jonathan Wilkes -
Pierre Massat