My modifications to CHDK

[cyril42e]

Only small things, what do you (users & devs) think of these?
All these modifications suggestions have been successfully tested on my SD1000. Diffs are against r412, but just designed as reminders to do it manually. I can make a true patch against any release (or branche) with the desired features...

1. Fix get_nr_raw ubasic command [juciphox-416]

I guess this is a bug fix, because everything has already been prepared to include this command, except one line:

Code

GeSHi (diff):
lib/ubasic/tokenizer.c:116
+	{"get_raw_nr",                 TOKENIZER_GET_RAW_NR},
 
Created by GeSHI 1.0.7.20

This is very useful when want to use set_nr_raw and to restore the state of the camera at the end of the script.

2. Add get_raw ubasic command [juciphox-416]

Same thing that get_raw, useful to restore the state of the camera.

A little bit more stuff to do:

Code

GeSHi (diff):
lib/ubasic/tokenizer.h:143
+	TOKENIZER_GET_RAW,
lib/ubasic/tokenizer.c:117
+	{"get_raw",                     TOKENIZER_GET_RAW},
lib/ubasic/ubasic.c:220
+	case TOKENIZER_GET_RAW:
+		accept(TOKENIZER_GET_RAW);
+		r = ubasic_camera_get_raw();		 
+		break;
core/conf.c:90
+
+int ubasic_camera_get_raw()
+{
+	// "Off", "On"
+	return conf.save_raw;
+}
include/platform.h:414
+int ubasic_camera_get_raw();
 
Created by GeSHI 1.0.7.20

3. Force restoring when interrupting script [juciphox-417]

I like restoring the state of the camera at the end of scripts. Problem: if the user interrupts the script pressing shoot_full, nothing is restored. For instance for picture size, when I change the propcase it is taken into account but the Canon GUI still displays the previous setting, so the user cannot know that the size has changed: very annoying. So at first I was scruting the buttons in the script loop, and if the user pressed shoot_half it went directly to restoring. But you have to warn the user at first to use shoot_half instead of shoot_full to interrupt the script, you're not sure he will do it, and keys scrutation is not very reliable. In brief, it's very dirty.

So my solution: when shoot_full is clicked during script execution, CHDK tries to jump to a label called "restore". If it doesn't exist, script is interrupted. If restoring is too long and the user clicks a second time shoot_full, then script is interrupted (so there is always a way to interrupt script execution whatever crazy stuff there is after "restore" label).

The diff file (not that long):

Code

GeSHi (diff):
lib/ubasic/ubasic.c:405
-static int
+int
 jump_label(char * label)
lib/ubasic/ubasic.h:57
+int jump_label(char * label);
lib/ubasic/ubasic.c:50
 #endif
+#include "../../include/conf.h"
lib/ubasic/ubasic.c:425
+if (state_kbd_script_run == 1) {
 	DEBUG_PRINTF("Label %s not found", label);
 	ubasic_error = UBASIC_E_UNK_LABEL;
+}
 return 0;
core/kbd.c:454
 if (!state_kbd_script_run){
 	script_console_clear();
 	script_console_add_line(lang_str(LANG_CONSOLE_TEXT_STARTED));
 	script_start();
-} else {
+} else
+if (state_kbd_script_run == 2)
+{
 	script_console_add_line(lang_str(LANG_CONSOLE_TEXT_INTERRUPTED));
 	script_end();
+} else
+{
+	state_kbd_script_run = 2;
+	if (jump_label("restore") == 0)
+	{
+		script_console_add_line(lang_str(LANG_CONSOLE_TEXT_INTERRUPTED));
+		script_end();
+	}
+}
 
Created by GeSHI 1.0.7.20

4. First element selected when opening menu [juciphox-416]

When you open a menu or enter a submenu, no line is selected by default. So you have to click one button to select one line (either the first one or the last one). I don't feel it very intuitive, and I prefer when the first line is selected by default, and you save one click when you want to go down!

So is there a good reason why it is like that? What do you guys prefer?

Here is what to do to change it:

Code

GeSHi (diff):
core/gui_menu.c:51
-gui_menu_set_curr_menu(menu_ptr, 0, -1);
+gui_menu_set_curr_menu(menu_ptr, 0, 0);
core/gui_menu.c:241
-gui_menu_set_curr_menu((CMenu*)(curr_menu->menu[gui_menu_curr_item].value), 0, -1);
+gui_menu_set_curr_menu((CMenu*)(curr_menu->menu[gui_menu_curr_item].value), 0, 0);
core.gui_menu.c:275
-gui_menu_set_curr_menu(curr_menu, 0, -1);
+gui_menu_set_curr_menu(curr_menu, 0, 0);
core.gui_menu.c:283
-gui_menu_set_curr_menu((CMenu*)(curr_menu->menu[gui_menu_curr_item].value), 0, -1);
+gui_menu_set_curr_menu((CMenu*)(curr_menu->menu[gui_menu_curr_item].value), 0, 0);
 
Created by GeSHI 1.0.7.20

5. Modulo in file browser navigation [juciphox-416]

Just like the previous thing, I didn't feel intuitive to not being able to go to the last line by clicking up on the first line (and to the first clicking down on the last one), like in the menus. So again are there good reasons, what do you prefer ? (it is still possible to use zoom_in and zoom_out to go quickly to the first or last line).

So if you want to do it.

Code

GeSHi (diff):
core/gui_fselect.c:363
-	register int j;
+	register int j, i;
core/gui_fselect.c:368
 	if (selected->prev) 
 		selected=selected->prev;
+	else
+	if (step == 1)
+	{
+		for(; selected->next; selected=selected->next);
+		for (i=0, top=selected; i<NUM_LINES-1 && top->prev; ++i, top=top->prev);
+	}
core/gui_fselect.c:383
 	if (selected->next) 
 		selected=selected->next;
+	else
+	if (step == 1)
+	{
+		for(; top->prev; top = top->prev);
+		selected = top;
+	}
 
Created by GeSHI 1.0.7.20

6. Swap zoom_in/out for increment value change

I'm starting to wonder if I'm "normal", but once again I don't feel intuitive at all to increase the increment using zoom_out, and to decrease it using zoom_in. I mean when you start up your camera, it is zoomed out, and if you want to change the zoom you will zoom in, and if you want to restore you will zoom out. Here when you begin the increment is 1, so if you want to change it you should use zoom in, and if you want to restore it to use zoom out...

What do you think?...

Trivial diff:

Code

GeSHi (diff):
gui_menu.c:316
-case KEY_ZOOM_IN:
+case KEY_ZOOM_OUT:
-case KEY_ZOOM_OUT:
+case KEY_ZOOM_IN:
 
Created by GeSHI 1.0.7.20

7. Fix alt-button click in alt-mode triggers original function [juciphox-417]

I already created a ticket on CHDK trac, but it doesn't seem to really be used...

A short click on alt-button is supposed to switch alt-mode, and a long click to trigger the original function of the button.

It works when you are outside alt-mode, but when you are inside alt-mode short click both exits alt-mode AND triggers original function of alt-button. Consequently you cannot exit alt-mode without triggering the original function of the alt-button, so the long click emulation is useless.

The problem is that given the existing structure of the kbd_process function, it was impossible to fix this, because it was managing the delay emulation with the same code for both alt-mode and normal-mode, but always in alt-mode. Thus I had to organize differently the function and that's quite a lot of lines changed, so it should be tested by several people to ensure that bugs weren't introduced during the process before to include it somewhere (I tested it and it seems ok, but we are never sure...).

I also restored the auto iso shift management because it seems to work perfectly (do you know why it was commented out?), and fixed a small possible bug: when the alt-button is released between CAM_EMUL_KEYPRESS_DELAY and CAM_EMUL_KEYPRESS_DELAY+CAM_EMUL_KEYPRESS_DURATION, then the emulated alt-button was never released (that's only 50ms but...).

Code:

core/kbd.c:334
-long kbd_process()
-{
-/* Alternative keyboard mode stated/exited by pressing print key.
- * While running Alt. mode shoot key will start a script execution.
- */
-
- if (kbd_blocked){
- if (key_pressed){
- if (kbd_is_key_pressed(conf.alt_mode_button)) {
- ++key_pressed;
- if (key_pressed==CAM_EMUL_KEYPRESS_DELAY) {
- kbd_key_press(conf.alt_mode_button);
- } else if (key_pressed==(CAM_EMUL_KEYPRESS_DELAY+CAM_EMUL_KEYPRESS_DURATION)) {
- kbd_key_release(conf.alt_mode_button);
- key_pressed = 2;
- kbd_blocked = 0;
-// gui_kbd_leave();
- }
- } else if (kbd_get_pressed_key() == 0) {
- if (key_pressed!=100)
- gui_kbd_enter();
- key_pressed = 0;
- }   
- return 1;
- }
-
- if (kbd_is_key_pressed(conf.alt_mode_button)){
- key_pressed = 2;
- kbd_blocked = 0;
- gui_kbd_leave();
- return 1;
- }
-
- if (kbd_is_key_pressed(KEY_SHOOT_FULL)){
- key_pressed = 100;
- if (!state_kbd_script_run){
- script_console_clear();
- script_console_add_line(lang_str(LANG_CONSOLE_TEXT_STARTED));
- script_start();
- } else {
- script_console_add_line(lang_str(LANG_CONSOLE_TEXT_INTERRUPTED));
- script_end();
- }
- }
-
- if (state_kbd_script_run)
- process_script();
- else {
- gui_kbd_process();
- }
- } else {
-
-// if (kbd_is_key_pressed(KEY_SHOOT_HALF) && kbd_is_key_pressed(conf.alt_mode_button)) return 0;
-
- if (!key_pressed && kbd_is_key_pressed(conf.alt_mode_button)){
- kbd_blocked = 1;
- key_pressed = 1;
- kbd_key_release_all();
-// gui_kbd_enter();
- return 1;
- } else
- if ((key_pressed == 2) && !kbd_is_key_pressed(conf.alt_mode_button)){
- key_pressed = 0;
- }
-       
- if (conf.use_zoom_mf && kbd_use_zoom_as_mf()) {
- return 1;
- }
- }
-
- return kbd_blocked;
-}
+long kbd_process()
+{
+/* Alternative keyboard mode stated/exited by pressing print key.
+ * While running Alt. mode shoot key will start a script execution.
+ */
+ // deals with alt-mode switch and delay emulation
+ if (key_pressed)
+ {
+ if (kbd_is_key_pressed(conf.alt_mode_button) ||
+ ((key_pressed >= CAM_EMUL_KEYPRESS_DELAY) &&
+ (key_pressed < CAM_EMUL_KEYPRESS_DELAY+CAM_EMUL_KEYPRESS_DURATION)))
+ {
+ if (key_pressed <= CAM_EMUL_KEYPRESS_DELAY+CAM_EMUL_KEYPRESS_DURATION)
+ key_pressed++;
+ if (key_pressed == CAM_EMUL_KEYPRESS_DELAY)
+ kbd_key_press(conf.alt_mode_button);
+ else if (key_pressed == +CAM_EMUL_KEYPRESS_DELAY+CAM_EMUL_KEYPRESS_DURATION)
+ kbd_key_release(conf.alt_mode_button);
+ return 1;
+ } else
+ if (kbd_get_pressed_key() == 0)
+ {
+ if (key_pressed != 100 && (key_pressed < CAM_EMUL_KEYPRESS_DELAY))
+ {
+ kbd_blocked = 1-kbd_blocked;
+ if (kbd_blocked) gui_kbd_enter(); else gui_kbd_leave();
+ }
+ key_pressed = 0;
+ return 1;
+ }
+ return 1;
+ }
+
+ // auto iso shift
+ if (kbd_is_key_pressed(KEY_SHOOT_HALF) && kbd_is_key_pressed(conf.alt_mode_button)) return 0;
+       
+ if (kbd_is_key_pressed(conf.alt_mode_button))
+ {
+ key_pressed = 1;
+ kbd_key_release_all();  
+ return 1;
+ }
+
+ // deals with the rest
+ if (kbd_blocked)
+ {
+ if (kbd_is_key_pressed(KEY_SHOOT_FULL))
+ {
+ key_pressed = 100;
+ if (!state_kbd_script_run)
+ {
+ script_console_clear();
+ script_console_add_line(lang_str(LANG_CONSOLE_TEXT_STARTED));
+ script_start();
+ } else
+ {
+ script_console_add_line(lang_str(LANG_CONSOLE_TEXT_INTERRUPTED));
+ script_end();
+ }
+ }
+
+ if (state_kbd_script_run)
+ process_script(); else
+ gui_kbd_process();
+ } else
+ {
+ if (conf.use_zoom_mf && kbd_use_zoom_as_mf())
+ return 1;
+ }
+
+ return kbd_blocked;
+}

(be careful, modification #3 changes some code in this function, that is not taken into account here)

EDIT 2008/06/17
8. Don't show script params if no param [juciphox-424]

I don't know why, but when a script has no parameter, three parameters a/b/c are still shown. I don't like it, because visually you think there are parameters so you read them, just to see that there are actually no parameter, and you just waste time... I guess the idea was to provide three parameters without having to declare them, but honestly it's not difficult to declare parameters when you need it, and you can give an actual title, so I don't think these automatic params are worth the pain. What do you think?

My modifications to CHDK

9. Display zebra only when necessary [juciphox-424]

When zebra are displayed, all the built-in OSD disappears. That's without doubt why the "Blink#" zebra modes exist, but I still feel annoying that the OSD blink too. So what I did is to not drawing zebra at all when there is no under/over-exposed region, so that the built-in OSD is still there. It has another advantage: you'll see more easily when there are under/over-exposed regions, because your OSD will disappear/blink in addition to the actual zebra. And if no problem, no pain.

My modifications to CHDK

EDIT 2008/06/22
11. Save script parameters values and parameters sets [juciphox-428]

Instead of initializing parameters with default values when a script is loaded, they are initialized with the same value than last time the script was run. Parameters values are stored in a file A/CHDK/DATA/script-name.cfg, with the same syntax than script header (@param & @default). Parameter descriptions are compared and value is restored only if it hasn't changed. Values are saved when the script is started. There is a new menu item "Load default param values" to load default values instead of saved values.
You can also save up to 10 different parameters sets for each script, and switch easily between them.

My modifications to CHDK

EDIT 2008/06/27
12. Show and erase RAW in review mode

So the idea is, when in review mode:
- to display in OSD if there is a RAW file corresponding to the current viewed JPG
- to allow in alt-mode RAW deletion (disp button), but also navigation between pictures (left/right) and jpg deletion (bottom) like outside alt-mode

My modifications to CHDK

The current viewed file name address is maybe platform dependent...


I'm waiting for your feedback!

[hiker_jon]

Hi,

I tried out 4,5,6 and like them very much. 
Jon

[PhyrePhoX]

i also like all of these features.
some of them were included by jucifer in our branch, and someday it will be included in the trunk if have nothing against it.
the trac/assembla ticket system is rarely used, thats why opening a "ticket" in the forum is much better than opening it there. thanks for your contributions!

[cyril42e]

Wow, already included, cool! :-)
I like this idea of "collaborative CHDK", too.

What did you like less in those that weren't included? Is it because they are modifying more critical parts, or it is less useful, or not reliable enough, or some other reasons?

Actually I mainly care for #3, because I like it very much, and it changes the way I write my scripts, so if I want to publish them one day...

Thanks!

[Jucifer]

Ok, #3 and #7 added to the juciphox branch.
(I hope I got them right... You might want to check. ;)

[cyril42e]

Great, thanks :-), hope I didn't look like I was insisting too much :-s.
I had a look at the changeset, and I tested it: it seems ok, thanks again !

[cyril42e]

Two more:

8. Don't show script params if no param

I don't know why, but when a script has no parameter, three parameters a/b/c are still shown. I don't like it, because visually you think there are parameters so you read them, just to see that there are actually no parameter, and you just waste time... I guess the idea was to provide three parameters without having to declare them, but honestly it's not difficult to declare parameters when you need it, and you can give an actual title, so I don't think these automatic params are worth the pain. What do you think?

(against juciphox-423)

Code

GeSHi (diff):
core/script.c:155
-if (i==SCRIPT_NUM_PARAMS) { // there was no @param in script
-    for (i=0; i<3; ++i) {
-        strcpy(script_params[i], "Var. ? value");
-        script_params[i][5]='a'+i;
-    }
-}
 
Created by GeSHI 1.0.7.20

9. Display zebra only when necessary

When zebra are displayed, all the built-in OSD disappears. That's without doubt why the "Blink#" zebra modes exist, but I still feel annoying that the OSD blink too. So what I did is to not drawing zebra at all when there is no under/over-exposed region, so that the built-in OSD is still there. It has another advantage: you'll see more easily when there are under/over-exposed regions, because you're OSD will disappear/blink in addition to the actual zebra. And if no problem, no pain.

Code

GeSHi (diff):
core/gui_osd.c:246
+int zebra_drawn=0;
core/gui_osd.c:303
-int step_x, step_v;
-over = 255-conf.zebra_over;
-if (conf.zebra_multichannel) {step_x=2; step_v=6;} else {step_x=1; step_v=3;}
-for (s=0, y=1, v=0; y<=viewport_height; ++y) {
-	for (x=0; x<screen_width; x+=step_x, s+=step_x, v+=step_v) {
-		register int yy, uu, vv;
-		int sel;
-		yy = img_buf[v+1];
-		if (conf.zebra_multichannel) {
-			uu = (signed char)img_buf[v];
-			vv = (signed char)img_buf[v+2];
-			sel=0;
-			if (!((conf.zebra_mode == ZEBRA_MODE_ZEBRA_1 || conf.zebra_mode == ZEBRA_MODE_ZEBRA_2) && (y-x-timer)&f)) {
-				if (((yy<<12) +			 vv*5743 + 2048)>>12>over) sel	= 4; // R
-				if (((yy<<12) - uu*1411 - vv*2925 + 2048)>>12>over) sel |= 2; // G
-				if (((yy<<12) + uu*7258			 + 2048)>>12>over) sel |= 1; // B
-			}
-			buf[s]=buf[s+1]=cls[sel];
-		}
-		else if (((conf.zebra_mode == ZEBRA_MODE_ZEBRA_1 || conf.zebra_mode == ZEBRA_MODE_ZEBRA_2) && (y-x-timer)&f)) buf[s]=COLOR_TRANSPARENT;
-			 else buf[s]=(yy>over)?cl_over:(yy<conf.zebra_under)?cl_under:COLOR_TRANSPARENT;
-	}
-	s+=screen_buffer_width-screen_width;
-	if (y*screen_height/viewport_height == (s+screen_buffer_width)/screen_buffer_width) {
-		memcpy(buf+s, buf+s-screen_buffer_width, screen_buffer_width);
-		s+=screen_buffer_width;
-	}
-}	
core/gui_osd.c:288
}
++if (f)
++{
+	int step_x, step_v;
+	over = 255-conf.zebra_over;
+	if (conf.zebra_multichannel) {step_x=2; step_v=6;} else {step_x=1; step_v=3;}
+	for (s=0, y=1, v=0; y<=viewport_height; ++y) {
+		for (x=0; x<screen_width; x+=step_x, s+=step_x, v+=step_v) {
+			register int yy, uu, vv;
+			int sel;
+			yy = img_buf[v+1];
+			if (conf.zebra_multichannel) {
+				uu = (signed char)img_buf[v];
+				vv = (signed char)img_buf[v+2];
+				sel=0;
+				if (!((conf.zebra_mode == ZEBRA_MODE_ZEBRA_1 || conf.zebra_mode == ZEBRA_MODE_ZEBRA_2) && (y-x-timer)&f)) {
+					if (((yy<<12) +			 vv*5743 + 2048)>>12>over) sel	= 4; // R
+					if (((yy<<12) - uu*1411 - vv*2925 + 2048)>>12>over) sel |= 2; // G
+					if (((yy<<12) + uu*7258			 + 2048)>>12>over) sel |= 1; // B
+				}
+				buf[s]=buf[s+1]=cls[sel];
+			}
+			else if (((conf.zebra_mode == ZEBRA_MODE_ZEBRA_1 || conf.zebra_mode == ZEBRA_MODE_ZEBRA_2) && (y-x-timer)&f)) buf[s]=COLOR_TRANSPARENT;
+				 else buf[s]=(yy>over)?cl_over:(yy<conf.zebra_under)?cl_under:COLOR_TRANSPARENT;
++			if (buf[s] != COLOR_TRANSPARENT && !zebra_drawn) zebra_drawn = 1;
+		}
+		s+=screen_buffer_width-screen_width;
+		if (y*screen_height/viewport_height == (s+screen_buffer_width)/screen_buffer_width) {
+			memcpy(buf+s, buf+s-screen_buffer_width, screen_buffer_width);
+			s+=screen_buffer_width;
+		}
+	}	
++	if (!zebra_drawn) f=0;
++}
if (!f) {
 
Created by GeSHI 1.0.7.20

10. Fix Histo/DOF not cleared in alt-mode on shoot_half release

When histogram or DOF values are set to be displayed only when shoot_half, it's ok outside alt-mode, but in alt-mode:
- other OSD values are not hidden like outside alt-mode
- when shoot_half is released, histo and DOF are not cleared (though not updated)

Problem:  I miserably failed fixing this. I looked everywhere where KEY_SHOOT_HALF and GUI_MODE_ALT/NONE appeared, but I couldn't find where the screen is cleared outside alt-mode and not inside alt-mode... neither where other osd info are hidden btw. Any hint?

11. Save script parameters values

Suggestion now (I will do it if people are interested in).
When a script is loaded, parameters are initialized with default values. What do you think of initializing them with the same value than the last time it was used instead? (saved in a file, and with a menu item to set default values)

[Jucifer]

Added 8 and 9.

I think 11 has been requested before. If you have the enthusiasm, go for it. :]

[NewbieToobie]

I read somewhere that the reason the a,b,c script letters are there is that you can change them even if they're not defined in a script. Makes writing scripts faster if all you need is 3 variables to use. A shame to lose that. It's not a cosmetic error. I think it's in the Wikia somewhere.

[Jucifer]

Either way is fine by me. Would an option to set the number of definable parameters be a bit overkill? ;]

edit: Ok, done. Now, should I commit this..? :]

[fudgey]

Just my 5 cents or so, but I find the default a b c parameter thing quite unnecessary, confusing and ugly... I don't have any need for such a quick way to access the three first parameter letters (I can't remember what a parameter does unless I give it a proper description anyway, and since we can't create scripts in-camera, there's always time for those 10 seconds it takes to finish the script by copy-pasting a @param/@default line from an old script).

I do have use for scripts with no parameters, and I have created one or two with a single dummy parameter to make those three default ones go away.

And cyril42e, keep up the good work polishing some of the rough edges in CHDK (and whatever you may come up with), your improvements are very welcome!

Btw, #11 really is a familiar feature request and it is something I'd find very useful. There should probably be some sort of detection for changes in the script, though, to prevent odd behavior when the script is updated and parameter assignments change (like a script file checksum stored in the config file, or just a simple file date and size check while loading the script).

[cyril42e]

Added 8 and 9.

edit: Ok, done. Now, should I commit this..? :]

As it could be understood from my post, I completely agree with fudgey. From my point of view there is no advantage to these default variables, because it's encouraging bad practice. But if some people really do want to keep this feature, your solution could be a good compromise . Happy not to have to decide .

I think 11 has been requested before. If you have the enthusiasm, go for it. :]

I'll go for it

Btw, #11 really is a familiar feature request and it is something I'd find very useful. There should probably be some sort of detection for changes in the script, though, to prevent odd behavior when the script is updated and parameter assignments change (like a script file checksum stored in the config file, or just a simple file date and size check while loading the script).

Very good point! I'll see what I can do. Thanks!

And cyril42e, keep up the good work polishing some of the rough edges in CHDK (and whatever you may come up with), your improvements are very welcome!

Thank you for your encouragement!

[cyril42e]

So here it is:

11. Save script parameters values
Instead of initializing parameters with default values when a script is loaded, they are initialized with the same value than last time the script was run. Parameters values are stored in a file A/CHDK/DATA/script-name.cfg, with the same syntax than script header (@param & @default). Parameter descriptions are compared and value is restored only if it hasn't changed. Values are saved when the script is started. There is a new menu item "Load default param values" to load default values instead of saved values.

EDIT: now manages parameters sets too. Latest diff file: 11_script-params-sets_r5_juciphox427.svn.diff


Suggestion: instead of having a script submenu:

...
----- Current script -----
script-name
------- Parameters -------
param1                  [4]
param2                  [2]
...

why not having:

...
------- script-name -------
param1                  [4]
param2                  [2]
...

It would save two lines, available to display more script parameters without scrolling (ie you can see them directly) (I suggest that because I added one menu item and it hides one more parameter . But it may not be clear anymore for newbies that there are parameters...)

[wontolla]

Woooow cyril42e!

Let me be the first to congratulate you.

I use to have sets of files with different default parameters for my timelapses, it was a mess. But not anymore!

Downloading your changes...

[cyril42e]

Let me be the first to congratulate you.

Thanks (however that's nothing compared to what other CHDK developers are doing )

I use to have sets of files with different default parameters for my timelapses, it was a mess. But not anymore!

Not sure to understand... You can only save one set of parameters, so you still will have to change them if you want different sets of parameters...?

It would be possible to implement saving of different parameters sets though. The easy way would be one more menuitem "int" to chose the parameters set, parameters are automatically saved to the given set (so no name, and no delete, only overwrite). Is that what you would like wontolla?

EDIT: done, new diff file

Oh, concerning the mess in scripts, I had another idea: being able to call scripts from inside scripts. Something like:
script <scriptname> [param1] [param2] ...
Some work to do to save the context (maybe allowing only one degree of inclusion), but it would be more readable and reliable than including them manually, having to change variable names, and propagate changes etc...