[bang (
|
[r array1]
|
[savepanel]
|
[symbol]
|
[write $1.txt (
|

and 'till here all works fine (i.e. the .txt is written well)

then i use openpanel:

[bang (
|
[r array1]
|
[savepanel]
|
[t b b s]
| | |
| [symbol]
| |
[write $1.txt (
| |
|
|
[subpatch in where all parameters are rerouted to their destination (in the same order of the previuos subpatch)]

This seems to work fine, but somewhere the parameters are correctly received somewhere only some, somewhere else not at all (i've noticed it behaves following a routine: what works will continue working and viceversa) and it's strange: i've used copy and paste.
please help me, i'm driving crazy!

Did I understand you correctly?

cian, i think your problem might be in the subpatch.. do you want to post it for us?

apart from the small syntax error posted below, i can't see why your construction wouldn't work...

i don't understand this bit:

[bang (
|
[r array1]
|
[savepanel]

what's the [r array1] for?? as far as i know [open/savepanel] only take a bang, so the [receive] object shouldn't be there.

to obiwannabe:
textfile doesn't seem necessary: opening in a text editor the saved file all the numbers are stored exactly as they have to be, and also when reloading parameters the array is drawn well. The Source be with you

to hardoff:
you're right, [r array1] is redundant. actually in my patch there's non bang but a bang receiver (probably for that i posted it)

... and here're save and load subpatches:

SAVE

[r $xy] [loadbang]
| |
| [nr. = position in the array (
| |
[tabwrite array1]

(i've about 15 of these per table and 10 tables (all with different names), but i don't think this is the point)

LOAD

[inlet receiving the bang from upper level]
|
[nr. = position in the array (
|
[tabread array1]
|

if they are all called that, then you are probably getting errors by having multiple subpatches with the same send names.

please just attach your patch to a message here. it will be much easier to find the problem.

instead of 'quick post' hit 'post reply' and you will get a browser button for attachments.

tons of thanks for your assistance

http://www.pdpatchrepo.info/hurleur/presets.pd

the stuff you posted originally about the [openpanel] and the [t b b s] all seems to be ok. i checked through it, and nothing seems to be out of order.

so then i read your post again, and you said that the Q and FW sections are working fine, but the q, w, e, r sections have trouble.

so, i looked at those sections, and found one main difference:

the Q and FW saver sections all only write one float value into the tables.

HOWEVER, your q,w,e,r saver sections contain [unpack] objects, and distribute those numbers to various tables.

for example:

[pd MW-q-saver] starts with:

[r $MWq-llfo]
|
[unpack f f f f f f f f f f]

i think somewhere, when you are packing those numbers together, you may have an error.

have a look and see if that's your problem.

also, i don't think this is the source of your errors, but as far as i know,
is not really 'correct' in pd. for sends and receives, you can use $0-abcd, $1abcd, $999xyz, etc...but the $ is meaningless without a number after it.

anyway, for the moment have a look at how you are using [pack] and [unpack] because i think you may find an error there somewhere.

also, try to save some presets in your q,w,e,r sections, and then open the textfiles in a text editor and see if you get the numbers you expected. if the numbers are correct, then you know that your save mechanism is working, so the error must be in the load mechanism. vice versa, if the textfile numbers are wrong, then you know you are making a mistake when saving the text.

good luck. it looks like an interesting project. are you using pd to control your beehive or something???

i'm sorry for that syntax error (i didn't cared so much the manual, i preferred to learn while using, so... ) slowly i will correct them all, and you were right is surely not that my problem (i tried).

and, yes you're right. my life-time aim is to control a bumblebee-hive through pd, actually my dream is to be a cuckoo bumblebee (there's a lot of fun... trust me: search for informations) (i'm italian and here we say cucù (same pronounce as cuckoo) as to say "Surprise!")

http://www.pdpatchrepo.info/hurleur/mworkers.pd

there is a giant queen bee from a separate hive sending messages to your male workers and they are eating parts of your patch.

no,

actually your problem is with undefined cable order to your pack object in the male workers patch.

the section where you have number boxes connected to the [pack] object also has those number boxes connected to a [bang]. however, you need to include a trigger to tell the numbers to go to the pack object BEFORE the bang object.

it's annoying, but for every number box, you will need to add [t b f], so that the float gets sent to the [pack] before its first inlet is banged.

please send me some of the honey when your project is finished

thanks a lot. right now i'm away from my computer (a sort of holyday away from pd, i was too addicted...) i'll try as soon as possible.

here i am again, finally. i'm so sorry to tell you wasn't that the problem. anyway i'm really thinking about abandoning this improvement for my project.

... honey's coming...

http://www.pdpatchrepo.info/hurleur/cuckoo_3.0.zip