hi, sorry for my bothering, I really don't know, what I am doing wrong. I simply copied the array example from the help-files, changed some names and for any reason the array in my data-field is not drawn correctly anymore :( I expected it to look about the same as in the example patch, but is is simply a line, and I also cannot draw the elements. maybe someone can help me, because I do not see, what I am doing wrong - I am sure, it is only a stupid mistake... thanks! marius.
#N struct template6 float id float IP1 float IP2 float nix array times1 template6-element; #N struct template6-element float t; #N canvas 350 165 450 300 10; #X text -15 325 unterscheide struktur und inhalt!; #X text -15 343 Inhalt ist im data subpatch; #X text -15 363 Struktur in template1 und page elements; #X text 32 444 jedesmal append...?; #N canvas 0 0 956 300 data6 0; #X scalar template6 50 150 30 9 ; 0 ; 0 ; 0 ; 0 ; 0 ; 3 ; 0 ; 0 ; 0 ; 7 ; -30 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 43 ; 0 ; 0 ; 0 ; 0 ; ;; #X restore 83 140 pd data6; #N canvas 435 84 589 429 stuff 0; #X obj 395 157 pointer; #X obj 136 102 t b b b; #X msg 136 61 bang; #X text 170 61 click here to re-initialize; #X msg 283 280 50; #X obj 137 23 loadbang; #X msg 134 140 50 150 30 9; #X obj 134 191 t b b p; #X floatatom 68 327 0 0 0 0 - - -; #X floatatom 14 332 0 0 0 0 - - -; #X obj 20 303 unpack; #X msg 12 258 3 5 , 7 9 , -30 10 , 43 45; #X msg 395 134 traverse pd-data6 , bang; #X msg 395 94 ; pd-data6 clear; #X obj 134 163 append template6 id IP1 IP2 nix; #X obj 284 307 setsize template6 times1; #X obj 68 350 element template6 times1; #X obj 14 376 set template6-element t; #X connect 0 0 14 4; #X connect 1 0 6 0; #X connect 1 1 12 0; #X connect 1 2 13 0; #X connect 2 0 1 0; #X connect 4 0 15 0; #X connect 5 0 2 0; #X connect 6 0 14 0; #X connect 7 0 11 0; #X connect 7 1 4 0; #X connect 7 2 15 1; #X connect 7 2 16 1; #X connect 8 0 16 0; #X connect 9 0 17 0; #X connect 10 0 9 0; #X connect 10 1 8 0; #X connect 11 0 10 0; #X connect 12 0 0 0; #X connect 14 0 7 0; #X connect 16 0 17 1; #X restore 275 129 pd stuff; #N canvas 182 49 577 300 template6 0; #X obj 37 45 struct template6 float id float IP1 float IP2 float nix array times1 template6-element; #X obj 38 118 plot times1 700 3 30 40 4; #X obj 36 89 filledpolygon 244 id 3 0 0 20 IP1 40 0; #X restore 83 171 pd template6; #N canvas 0 0 417 254 template6-element 0; #X obj 45 72 struct template6-element float t; #X restore 84 206 pd template6-element;
hi, to answer my own question... I went through Frank Barknecht's "128 is not enough" and found it there: "two field names are treated in a special way: float x and float y are used to specify the x- and y- coordinates of a structure's graphical representation." so I better should not have renamed those. marius.
Marius Schebella schrieb:
hi, sorry for my bothering, I really don't know, what I am doing wrong. I simply copied the array example from the help-files, changed some names and for any reason the array in my data-field is not drawn correctly anymore :( I expected it to look about the same as in the example patch, but is is simply a line, and I also cannot draw the elements. maybe someone can help me, because I do not see, what I am doing wrong - I am sure, it is only a stupid mistake... thanks! marius.
Yup. Good work!
On 9/8/06, Marius Schebella marius.schebella@chello.at wrote:
hi, to answer my own question... I went through Frank Barknecht's "128 is not enough" and found it there: "two field names are treated in a special way: float x and float y are used to specify the x- and y- coordinates of a structure's graphical representation." so I better should not have renamed those. marius.
Marius Schebella schrieb:
hi, sorry for my bothering, I really don't know, what I am doing wrong. I simply copied the array example from the help-files, changed some names and for any reason the array in my data-field is not drawn correctly anymore :( I expected it to look about the same as in the example patch, but is is simply a line, and I also cannot draw the elements. maybe someone can help me, because I do not see, what I am doing wrong - I am sure, it is only a stupid mistake... thanks! marius.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Fri, 8 Sep 2006, Marius Schebella wrote:
I went through Frank Barknecht's "128 is not enough" and found it there: "two field names are treated in a special way: float x and float y are used to specify the x- and y- coordinates of a structure's graphical representation." so I better should not have renamed those. marius.
Note that there's also a third special field name: w for width.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
Note that there's also a third special field name: w for width.
Yes, that's true. It's only used when you plot array elements, which isn't covered in my paper, so I left it out. However it occured to me that it is unfortunate that I still used a field called "w" in another context without mentioning its specialty.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Sat, 9 Sep 2006, Frank Barknecht wrote:
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
Note that there's also a third special field name: w for width.
Yes, that's true. It's only used when you plot array elements, which isn't covered in my paper, so I left it out. However it occured to me that it is unfortunate that I still used a field called "w" in another context without mentioning its specialty.
I don't know about your paper, it's just that while rewriting Miller's code I have to deal with a bunch of lines that are reading y, x, w. I still haven't really tried datastructures at all.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Sun, Sep 10, 2006 at 06:13:46PM -0400, Mathieu Bouchard wrote:
On Sat, 9 Sep 2006, Frank Barknecht wrote:
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
Note that there's also a third special field name: w for width.
Yes, that's true. It's only used when you plot array elements, which isn't covered in my paper, so I left it out. However it occured to me that it is unfortunate that I still used a field called "w" in another context without mentioning its specialty.
I don't know about your paper, it's just that while rewriting Miller's code I have to deal with a bunch of lines that are reading y, x, w. I still haven't really tried datastructures at all.
I recommend you learn the ins and outs of datastructures if you are rewriting Pd; most especially if you are adding lots of GUI stuff in DesireData. It's possible that some of the GUI things you are doing with DD could be done with Pd itself to the benefit of the larger community. I can't imagine someone re-writing or forking a piece of software without understanding one of it's major features.
Best,
Chris.
chris@mccormick.cx http://mccormick.cx
This is an interesting point that raises a question: How many of the GUI objects can be rewritten as data structures (and how difficult would it be to make some new ones using the technique (esp. to mimic the nice gui elements in Max)? I always remember seeing fleeting DS ideas on the list, but is there a repository on the main webpage for these creations?
~Kyle
On 9/11/06, Chris McCormick chris@mccormick.cx wrote:
On Sun, Sep 10, 2006 at 06:13:46PM -0400, Mathieu Bouchard wrote:
On Sat, 9 Sep 2006, Frank Barknecht wrote:
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
Note that there's also a third special field name: w for width.
Yes, that's true. It's only used when you plot array elements, which isn't covered in my paper, so I left it out. However it occured to me that it is unfortunate that I still used a field called "w" in another context without mentioning its specialty.
I don't know about your paper, it's just that while rewriting Miller's code I have to deal with a bunch of lines that are reading y, x, w. I still haven't really tried datastructures at all.
I recommend you learn the ins and outs of datastructures if you are rewriting Pd; most especially if you are adding lots of GUI stuff in DesireData. It's possible that some of the GUI things you are doing with DD could be done with Pd itself to the benefit of the larger community. I can't imagine someone re-writing or forking a piece of software without understanding one of it's major features.
Best,
Chris.
chris@mccormick.cx http://mccormick.cx
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Mon, Sep 11, 2006 at 11:39:16PM -0500, Kyle Klipowicz wrote:
This is an interesting point that raises a question: How many of the GUI objects can be rewritten as data structures (and how difficult would it be to make some new ones using the technique (esp. to mimic the nice gui elements in Max)? I always remember seeing fleeting DS ideas on the list, but is there a repository on the main webpage for these creations?
With Miller's latest changes to datastructures and [list] I think that many of the great GUIs like Yves' pianoroll can now be reproduced directly in Pd. Some of us like Frank have beeng making cool GUIs and sequencers and stuff for a long time, and I have no doubt that there will be full suites of excellent GUI objects in the near future, in addition to all those amazing things Frank et al have made already.
It would be cool if you could post some web links to the nice gui elements in Max/MSP that you are talking about. Check out the attached patch for my 3d-look win95ish GOP hack. :)
Best,
Chris.
chris@mccormick.cx http://mccormick.cx
On Tue, 12 Sep 2006, Chris McCormick wrote:
On Sun, Sep 10, 2006 at 06:13:46PM -0400, Mathieu Bouchard wrote:
I don't know about your paper, it's just that while rewriting Miller's code I have to deal with a bunch of lines that are reading y, x, w. I still haven't really tried datastructures at all.
I recommend you learn the ins and outs of datastructures if you are rewriting Pd;
Well, I'm sort of learning them now, though not at all the way most would learn about them. By reading and rewriting the source I get to know a bunch of functions with 11 or 14 or 19 arguments to them.
most especially if you are adding lots of GUI stuff in DesireData. It's possible that some of the GUI things you are doing with DD could be done with Pd itself to the benefit of the larger community.
Part of the problem with that is that a rewrite of the IEMGUI classes was one of the earliest things done in DesireData. I don't recall many suggesting back then that IEMGUI could be rewritten in structs. If anyone wants to attempt to do it, it would be cool.
I can't imagine someone re-writing or forking a piece of software without understanding one of it's major features.
If it's so major a feature then how come more people aren't using it? I believe that GEM is much more of a major feature of PureData.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Yes, this would be awesome! I think it could be done, but it would be tricky to be as functional without the properties menu, which is quite nice. There'd have to be a properties inspector patch, similar to the one made to edit canvases a while back.
~Kyle
On 9/13/06, Mathieu Bouchard matju@artengine.ca wrote:
most especially if you are adding lots of GUI stuff in DesireData. It's possible that some of the GUI things you are doing with DD could be done with Pd itself to the benefit of the larger community.
Part of the problem with that is that a rewrite of the IEMGUI classes was one of the earliest things done in DesireData. I don't recall many suggesting back then that IEMGUI could be rewritten in structs. If anyone wants to attempt to do it, it would be cool.
On Wed, 13 Sep 2006, Kyle Klipowicz wrote:
Yes, this would be awesome! I think it could be done, but it would be tricky to be as functional without the properties menu,
In DesireData you can do this to make sliders [hsl] and [vsl] be "normal objects" again instead of mapping to the Slider class:
class_new MySlider {ObjectBox} classinfo hsl MySlider classinfo vsl MySlider
Similar things can be done to most other GUI classes. However there is currently no way to undefine [hsl] and [vsl] at runtime: you'd still have to remove S(g_slider) from desire_setup. From that point you can define your own [hsl] and [vsl] as abstractions, and because above I used MySlider instead of using ObjectBox directly, you can define a custom properties dialog like this:
def MySlider popup_properties {} { set @blah [MySliderDialog new $self] } class_new MySliderDialog {PropertiesDialog} def MySliderDialog init {of} { super $of # here, add some widget creation inside of .$self # possibly using shortcut commands like: # $self add .$self {width integer} } def MySliderDialog apply {} { # here, pick up data and send it back to pd }
but then if you want to instead make it open a patch, I never tried, but it would be like:
def MySlider popup_properties {} { pd pd open sliderprops.pd some/directory/there }
but there's currently no mechanism that can tell that newly open patch to bind to a particular slider. what I see is that the soon-to-come "announce-future-object" feature will be useful:
def MySlider popup_properties {} { pd pd announce-future-object $self this_is_the_future pd pd open sliderprops.pd some/directory/there } def MySlider this_is_the_future {obj dollarzero} { pd $self here_it_is $dollarzero }
So the [hsl] or [vsl] abstraction instance will receive a here_it_is message in its leftmost [inlet] saying what's the $0, which you'd route using [route here_it_is]. Note that if the future-object is not a toplevel patch or abstraction-instance, the $0 wouldn't be passed. I just added that $0 idea to my former plan because the pointer ($obj above) can't really be handled by a patch.
Does that sound like a good idea?
Else, there could be a declarative class like [declare] or [block~] but which you would put in an abstraction instance to let it handle its own "Properties" menu entry.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hi Matju,
On Wed, Sep 13, 2006 at 04:58:06PM -0400, Mathieu Bouchard wrote:
On Tue, 12 Sep 2006, Chris McCormick wrote:
I recommend you learn the ins and outs of datastructures if you are rewriting Pd;
Well, I'm sort of learning them now, though not at all the way most would learn about them. By reading and rewriting the source I get to know a bunch of functions with 11 or 14 or 19 arguments to them.
That's cool, but it's a little bit like learning to drive by reading a book about the combustion engine.
Part of the problem with that is that a rewrite of the IEMGUI classes was one of the earliest things done in DesireData. I don't recall many suggesting back then that IEMGUI could be rewritten in structs. If anyone wants to attempt to do it, it would be cool.
I guess those work already, so what's the point in re-writing them? Which might apply to your situation too; you started DesireData some time ago so maybe lots of DD was implemented before datastructures became useful.
I can't imagine someone re-writing or forking a piece of software without understanding one of it's major features.
If it's so major a feature then how come more people aren't using it? I believe that GEM is much more of a major feature of PureData.
In general I would say that it takes a little while before drastically different new features start being used in software. I didn't use GEM for a number of years after learning Pd, and that isn't even new, just different. I would be interested to know where you get your data on the number of people using datastructures.
Best,
Chris.
chris@mccormick.cx http://mccormick.cx
On Mon, 18 Sep 2006, Chris McCormick wrote:
On Wed, Sep 13, 2006 at 04:58:06PM -0400, Mathieu Bouchard wrote:
Well, I'm sort of learning them now, though not at all the way most would learn about them. By reading and rewriting the source I get to know a bunch of functions with 11 or 14 or 19 arguments to them.
That's cool, but it's a little bit like learning to drive by reading a book about the combustion engine.
Fortunately I've already learned to drive elsewhere and so I can apply knowledge of how to use some other language's datastructures.
Part of the problem with that is that a rewrite of the IEMGUI classes was one of the earliest things done in DesireData. I don't recall many suggesting back then that IEMGUI could be rewritten in structs. If anyone wants to attempt to do it, it would be cool.
I guess those work already, so what's the point in re-writing them?
You know, it's rarely ever just a matter of whether the code does what it should do; it's also a matter of what else can we make it do. Let's call this the "beyondability factor". In this case this means, how easy it is to add new features to the code. If you want IEMGUI to stay the same forever, it doesn't matter; but if you want to make it do things that it can't do now, you don't want to have to learn C for that, and maybe you don't want to learn Tcl either.
Which might apply to your situation too; you started DesireData some time ago so maybe lots of DD was implemented before datastructures became useful.
I don't know when they became useful. I heard that 0.39 was a big boost; I rewrote IEMGUI in the middle of the 0.37 era; however, I believe that they were already useful back then, as Frank Barknecht taught them at PdConvention04.
In general I would say that it takes a little while before drastically different new features start being used in software.
Depends on how much "marketing" is put behind the features. Pd doesn't have enough marketing, the most it knows is people who say sorry for the spam when they announce their wonderful software. Then for some software the problems start before that. (e.g.: try to find any executables on gridflow.ca...)
I didn't use GEM for a number of years after learning Pd,
me neither, even though all I've been doing is video. now I'm teaching GEM, but it feels weird because I rarely ever use it.
and that isn't even new, just different.
uh, what do you mean?
I would be interested to know where you get your data on the number of people using datastructures.
By having attended PdConvention04 and Piksel05, by reading pd-list and pd-dev for four years, by founding the #dataflow channel and sitting in it for five years, and then, by organising twenty-two usergroup meetings that consist of 2-6 talks each.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Mon, Sep 18, 2006 at 02:32:49AM -0400, Mathieu Bouchard wrote:
On Mon, 18 Sep 2006, Chris McCormick wrote:
On Wed, Sep 13, 2006 at 04:58:06PM -0400, Mathieu Bouchard wrote:
Well, I'm sort of learning them now, though not at all the way most would learn about them. By reading and rewriting the source I get to know a bunch of functions with 11 or 14 or 19 arguments to them.
That's cool, but it's a little bit like learning to drive by reading a book about the combustion engine.
Fortunately I've already learned to drive elsewhere and so I can apply knowledge of how to use some other language's datastructures.
Datastructures in Pd are about graphical representation and user interface as much as they are about logical organisation of data, and I don't think that that aspect really becomes intuitive until you use them extensively. But whatever; if you want to hack the code without learning about it as a user, that is your prerogative.
Part of the problem with that is that a rewrite of the IEMGUI classes was one of the earliest things done in DesireData. I don't recall many suggesting back then that IEMGUI could be rewritten in structs. If anyone wants to attempt to do it, it would be cool.
I guess those work already, so what's the point in re-writing them?
You know, it's rarely ever just a matter of whether the code does what it should do; it's also a matter of what else can we make it do.
Yes, good point. I didn't see this because for me IEMGUIs do exactly what I need them to do. I can't see any addition to hslider for example that could make it easier for me to write electronic music, and they are concise modular representations of basic GUI elements that do one thing, and do it well. You are right though; this will not be true for everyone, and some people will want to extend the functionality of IEMGUIs.
Depends on how much "marketing" is put behind the features. Pd doesn't have enough marketing, the most it knows is people who say sorry for the spam when they announce their wonderful software. Then for some software the problems start before that. (e.g.: try to find any executables on gridflow.ca...)
Yep, agreed. Then again, Pd is pre-1.0 software.
and that isn't even new, just different.
uh, what do you mean?
Using Pd/GEM for graphics meant learning new things that I did not know when I used Pd for audio only. Pd/GEM is different from just Pd (but it has been around for a while).
I would be interested to know where you get your data on the number of people using datastructures.
By having attended PdConvention04 and Piksel05, by reading pd-list and pd-dev for four years, by founding the #dataflow channel and sitting in it for five years, and then, by organising twenty-two usergroup meetings that consist of 2-6 talks each.
That is a lot of experience and has obviously given you a good insight into certain kinds of Pd users, but it's all what I'd call anecdotal evidence. It would be nice to get actual survey data from users of this list as to what libraries, features, distributions of Pd people work with and hack on. Hmmm, maybe we (collectively) should knock together a nice survey?
Best,
Chris.
chris@mccormick.cx http://mccormick.cx
On 9/18/06, Chris McCormick chris@mccormick.cx wrote:
I would be interested to know where you get your data on the number of people using datastructures.
By having attended PdConvention04 and Piksel05, by reading pd-list and pd-dev for four years, by founding the #dataflow channel and sitting in it for five years, and then, by organising twenty-two usergroup meetings that consist of 2-6 talks each.
That is a lot of experience and has obviously given you a good insight into certain kinds of Pd users, but it's all what I'd call anecdotal evidence. It would be nice to get actual survey data from users of this list as to what libraries, features, distributions of Pd people work with and hack on. Hmmm, maybe we (collectively) should knock together a nice survey?
Speaking as a non-hacker, the datastructures are the only thing that makes me choose Pd over Max or Reaktor or Csound. -Chuckk
Hallo, Chris McCormick hat gesagt: // Chris McCormick wrote:
On Mon, Sep 18, 2006 at 02:32:49AM -0400, Mathieu Bouchard wrote:
By having attended PdConvention04 and Piksel05, by reading pd-list and pd-dev for four years, by founding the #dataflow channel and sitting in it for five years, and then, by organising twenty-two usergroup meetings that consist of 2-6 talks each.
That is a lot of experience and has obviously given you a good insight into certain kinds of Pd users, but it's all what I'd call anecdotal evidence. It would be nice to get actual survey data from users of this list as to what libraries, features, distributions of Pd people work with and hack on. Hmmm, maybe we (collectively) should knock together a nice survey?
Based on my reading pd-list for about 5-6 years, the number of user of data structures started to grow after the pd-convention, also through the tutorial I wrote for the workshop I did back then. Before that I only knew two people using data structures: Miller and Orm Finnendahl. The questions I posted re. data structures prior to the workshop were only answered by Miller.
The growing user base IMO was one of the reasons, that data structures got all the new features they got after the pd-convention. Without feedback it surely was hard for Miller to figure out ways to make his ideas - which are in Pd since 1996 - practical and useful.
But now, with "power users" like you or Chuck and others giving feedback and making wishes, there's a completely new drive in the ds-development. Of course data structures still have "issues" and they are a bit tricky to understand at first, but that didn't stop me from teaching them (I believe successfully) in beginner's workshops.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
I was about to say the coolest thing would be to be able to delete them. But as I think about it, it wouldn't be hard to make a patch that would set a certain flag to -1 in place of deleting a scalar, and then before appending new scalars, always search for any extant scalars with -1 in that value and alter their values instead of creating new scalars.
I've been wanting to ask advice on something. I'd like to put envelopes in my sequencer, so that they may be drawn as arrays, and the array values read back during performance. I think that each color would have a stack of arrays, for volume, panning, filters, effects. The recent feature for toggling drawing instructions makes this possible; otherwise the array would be over the notes constantly. So my question is: is it better to 1) set up one array per color per attribute per piece, and have it change size according to the length of the piece, or 2) to have separate arrays added whenever a value needs to change, and during playback the value stays at whatever its last value was while there is no array in a certain spot?
- would be far simpler to implement, and probably easier to use, but
- seems like it would be less CPU-intensive, as no values are read
until an array is present.
Am I making sense? Is there a cold hard answer, or is this one of those ambiguous questions?
-Chuckk
On Tue, 26 Sep 2006, Chuckk Hubbard wrote:
I was about to say the coolest thing would be to be able to delete them. But as I think about it, it wouldn't be hard to make a patch that would set a certain flag to -1 in place of deleting a scalar, and then before appending new scalars, always search for any extant scalars with -1 in that value and alter their values instead of creating new scalars.
I have no idea what you're talking about because I've never used DS, but I can tell you that scalars are part of a canvas in exactly the same way that all patchable objects are: they're all a big brochette - a kind of linked list in which each element points to the next one. In theory, scalars and patchables can be mixed in that list (though I don't know how much it can happen).
The common "class" of scalars (t_scalar) and patchables (t_text) is gobjects (t_gobj), which is obviously a lot generic than what we usually mean by GUI objects (which means t_text that use a custom t_widgetbehavior). The "brochette feature" is part of t_gobj.
There is already code for deleting any t_gobj you want from the brochette: that's what is used when you delete a patchable. There's just something at some point that prevents it.
To me, the "-1" flag is really not needed, but then I might be missing something... something like: a t_gpointer is not a weakref to a t_scalar, it's a weakref to a t_canvas with an extra unsafe pointer to the t_scalar, so the only way you can delete the t_scalar safely is by first deleting all t_gpointers that refer to it, but that's not possible... anyone correct me if I'm wrong. (I'll touch that code again eventually, but maybe not this year)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
To me, the "-1" flag is really not needed, but then I might be missing something... something like: a t_gpointer is not a weakref to a t_scalar, it's a weakref to a t_canvas with an extra unsafe pointer to the t_scalar, so the only way you can delete the t_scalar safely is by first deleting all t_gpointers that refer to it, but that's not possible... anyone correct me if I'm wrong. (I'll touch that code again eventually, but maybe not this year)
Late answer: It is already perfectly possible to delete a scalar in edit mode: Select it and press Backspace. What's missing is a way to do this though other means, e.g. by a message to the pointer or though a "disappend" object.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Tue, 3 Oct 2006, Frank Barknecht wrote:
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
so the only way you can delete the t_scalar safely is by first deleting all t_gpointers that refer to it, but that's not possible... anyone correct me if I'm wrong. (I'll touch that code again eventually, but maybe not this year)
Late answer: It is already perfectly possible to delete a scalar in edit mode: Select it and press Backspace. What's missing is a way to do this though other means, e.g. by a message to the pointer or though a "disappend" object.
ah cool, then if that feature is already safe in the sense that you can do that without risk of ever crashing [pointer] [get] [set] and stuff, then that should be easy to add to pd itself.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
ah cool, then if that feature is already safe in the sense that you can do that without risk of ever crashing [pointer] [get] [set] and stuff, then that should be easy to add to pd itself.
You will get "empty pointer" errors for example, if you deleted a scalar but still have a pending pointer delayed inside a [pipe p] object, if this pointer is sent out of [pipe] and/or gets to a [get]..., but indeed this doesn't crash Pd anymore. (It did in the past.)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On 10/3/06, Mathieu Bouchard matju@artengine.ca wrote:
On Tue, 3 Oct 2006, Frank Barknecht wrote:
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
so the only way you can delete the t_scalar safely is by first deleting all t_gpointers that refer to it, but that's not possible... anyone correct me if I'm wrong. (I'll touch that code again eventually, but maybe not this year)
Late answer: It is already perfectly possible to delete a scalar in edit mode: Select it and press Backspace. What's missing is a way to do this though other means, e.g. by a message to the pointer or though a "disappend" object.
ah cool, then if that feature is already safe in the sense that you can do that without risk of ever crashing [pointer] [get] [set] and stuff, then that should be easy to add to pd itself.
Cool. I don't know what the exact result is if one deletes a pointed-to scalar... I'm guessing an invalid pointer that needs to be reset. It may not seem like a big deal for most purposes, for Pd users, but being able to delete scalars automatically would facilitate setting up my sequencer so that the meter of an already-existing measure could be changed. Changing from 4/4 to 3/4, for instance, with all the later measures jumping forward (backward? er...leftward) and beats disappearing from the measure in question. Shifting the later measures is simple enough, just by subtracting a constant from all x values above n, but to change the measure in question, as Pd is now, would require keeping a record of the meter of every measure, and if a measure changes, clearing the score and redrawing everything.
-Chuckk
-
Chris McCormick -
Chuckk Hubbard -
Frank Barknecht -
Kyle Klipowicz -
Marius Schebella -
Mathieu Bouchard