some cyclone's objects don't resize

[porres]

[coll], [table], [prob], and [funbuff] can be resized but this is not saved in the patch when you reopen it - this is because they use 'embed' - this is better described below by Derek.

[derekxkwan]

note for later: this is caused by way embed works in a saved patch and we need a figure out a way of getting the zooming parameter and adding that to how these objects are saved

[porres]

note for later: this is caused by way embed works in a saved patch and we need a figure out a way of getting the zooming parameter and adding that to how these objects are saved

can you elaborate? :)

[derekxkwan]

kinda fuzzy on this, but like basically embed saves data in the patch right? like how arrays get saved and structs get saved and what not. these cyclone objects that save data, we have our own special way of storing and recalling data,.. i think,.. but this was pre-resizing abilities in pure data, and resize data also gets saved in the patch obv, so this is why these cyclone objects that save data don't resize, we need to relook at how these cyclone objects save data with the patch and account for these "new" resizing parameters that also get saved in the patch.

[porres]

we have our own special way of storing and recalling data

yeah, the embed info gets parsed to "hammerfile_new" here https://github.com/porres/pd-cyclone/blob/master/shared/common/file.c#L803

and also in "hammerfile_setup".

well, I'm not sure how to follow up on this one, do you think you can develop on this anytime @derekxkwan ?

[derekxkwan]

hmm, so it looks like the resizing appears in the save file following the object and its data as #X f (number), take for example a patch where i define [array define -k bob]

#N canvas 1130 538 450 300 12; #X obj 129 132 array define -k bob; #A 0 0 0 0 0 0 0 0 0 0.0533337 0.113335 0.133335 0.153335 0.200003 0.220003 0.240004 0.260004 0.280004 0.300005 0.313338 0.313338 0.313338 0.313338 0.293338 0.253337 0.200003 0.126668 0.0600005 0.013333 -0.0200009 -0.0733351 -0.113336 -0.153336 -0.160003 -0.37334 -0.37334 -0.37334 -0.37334 -0.360007 -0.33334 -0.320006 -0.300006 -0.273338 -0.253338 -0.226671 -0.193337 -0.0933354 0.0199998 0.113335 0.166669 0.233337 0.266671 0.293338 0.306671 0.313338 0.326672 0.326672 0.326672 0.326672 0.326672 0.326672 0.300005 0.24667 0.200003 0.146669 0.0333334 -0.18667 -0.233338 -0.253338 -0.273338 -0.273338 -0.273338 -0.286672 -0.293339 -0.293339 -0.293339 -0.293339 -0.293339 -0.293339 -0.293339 -0.293339 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0; #X f 2;

the 2 here means the array object gets resized to 2 characters wide (and when we don't resize or resize back to original size, the #X line doesn't appear.

when i try resizing [coll], this #X line doesn't appear at all in the save file, so i guess that hammerfile thing overrides normal save? (because i'm guessing #X is just something pd does now and [coll] doesn't do it,.. so we need to figure out how to get that resize width in characters from pd (maybe pd-dev list would know?) or somehow,.. not mess with normal pd save procedures (which mb would be preferred? bc what if there's another line that gets added in the future like #X that does something to pd save files? then we'd have this whole problem all over again). but thisss latter approach is prob way harder and not sure where to start with that...

[derekxkwan]

note: to get the width, the t_object x_ob in the _coll struct has it, so wherever it gets passed around, you can access it by x->x_ob.te_width,.... as to what actually does the saving,... have yet to figure that out...