remaining video,overrides-customizations,no-raw@video,just _random_ stuff :D

[PhyrePhoX]

well i guess there must be a way to find out max zoom steps directly in firmware (in chdk). maybe ewavr reads this and has an answer
plus, i assume canon doesnt mention zoom steps in all manual books, i mean "8 zoom steps" isnt that great feature to boast with

[wontolla]

PhyrePhoX:
It could be this way: if there's no feedback on a feature, it's either
- working flawless, or
- err... used by no one...

Jucifer is right. In my experience, it is the first case and that's why I didn't comment. Everything worked as advertised. Although the "cancel RAW during video" thing didn't work with my 64Mb SD card I use for CHDK tests, but with my 2Gb production ones did.

When one feature is working properly, nobody has further comments and the thread is buried. People are just waiting for these enhancements to be added. (And the desperate...well...we use Jucifer's YAP)

[PhyrePhoX]

thanks for your comment. well yes, i guess you are right. people usually only complain when things arent working, they seldom report things to work flawlessly. i will take my diffs and thread apart and supply several "finished" diffs so it will be easier to include it in official trunk.
regarding the disable raw@video issue: ur sure u used my build on that 64MB sd card?

[wontolla]

I tried again yesterday with my 64Mb card and disable raw@video worked.

The problem with this card is the buffer. Even for simple video, I have to reduce quality to 60%. Sloooooow card. But that's another isue.

[PhyrePhoX]

phew, and i thought i delivered buggy code
so, i think this can be neatly wrapped up and handed to allbest.
the stuff about ev correction and some ubasic commands will be left out for now though, as that definitly needs polishing.

[PhyrePhoX]

alright,

added following ubasic code:

get_zoom_steps - returns the possible zoomsteps (9 on a620, 129 on s3is for example)
get_nd_present - returns 0 if no ND present, 1 if ND present and real diaphragm NOT present, 2 if both ND & diaphragm present.
get_propset - returns 1 if propset 1,2 if propset is 2. propset 1 = digic II propsets, propset 2 = digic III propsets (see PropertyCase - CHDK Wiki )

now it should be possible to build universal scripts.

also i changed the random seed so that it uses luminance, tickcount & battery voltage. this (the random code) will be changed though, as it is still not "random enough".

i uncommented the experimental code that made it possible to quickly change ev via up/down buttons. have to find a way to use that on A-series (as up/down on these cams sets macro & flash already!).

i hope jucifer will add the diff to his build. will also cleanup the code soon so hopefully it will get submitted to official trunk, or at least parts of my code.
built against revision 390 (latest).

will post all binaries later (it is compiling at the moment...) and will also update first post.

Regarding Scripts: I did NOT delete or modify existing ubasic commands (thus my build wont break compatibility), HOWEVER, it *might* be possible that existing scripts will not work (probably hanging/crashing the camera), this is due to how the parser parses the code. IF some of your scripts do not work with my build, please report, it will be fixed. it is just a matter of "sorting" the ubasic commands so the the parser doesnt get a "hiccup".

edit: if you use my builds and you have used one of jucifers builds before, i advise you to backup your *.cfg file, and if any problems occur, delete the one from sdcard. these problems (if at all) should not occur if you wait for jucifer to include my diff into his build.
this is having to do with how the *.cfg file is built/parsed (it is not a bug!).

edit2: attached s3is build for barney, in case ( i do hope so) he still is coming here sometime.
edit3: darn, when looking at the errors.txt there is at least one case of an error introduced by me, seems i forgot to add movie_state to a definition of some cam somewhere. unfortunately the error.txt doesnt tell me in WHICH camera model this occurs. i figure it must be one of those newly added. will find out later.
also i noticed the tx1 isnt in the makefile yet, so there is no build for that, sorry (why is that by the way...?).

all binaries can be found here: zSHARE - 390_51_allbest_phyrephox.zip

edit4: tx1 probably is in the MAKEFILE, not in the makefile.inc. anyways, changed the diff so it compiles for tx1 as well.
edit5: tx1 binaries in the archive now
edit6: updated first post with ALL newly introduced ubasic commands (forgot that one time), so now in the first post you have a complete listing of all new ubasic commands which make life easier. for example the "yet another intervalometer" script can be made universal using my build now (just a hint, jucifer )

[Jucifer]

Sooo...

What about these modifications?

- separate iris-stuff from get_nd_present (to get_iris_present), both return 0/1 (or false/true in Lua) (also I might prefer without the get_)
- rename get_ready to get_shooting (propcase 205/206 is 0 when not shooting...) ("shooting" might be even better: do ... until shooting = 0 / repeat ... until not shooting())
I'd also like to change the uBASIC syntax of these, so they could be used without an intermediary variable.

Why is there "ubasic_camera_sleep(rand()%10);" in random_statement? 

[PhyrePhoX]

thanks for your comment.
well well,

if we seperate iris from nd it would mean that scripts that possibly want to use both iris and nd have to make TWO checks. not a big deal though. on the other hand, if properly documented in the wiki the 0,1,2 (as result from get_nd_present) can be of practical use.
i will change it though, the way you suggested it is a good way.

i mean, did anybody ever calculate the actual limit (in number of commands) the ubasic parser (or chdk in general) can handle? i mean, i would be happy to extend the list of available commands by many things (to make it more universal and practical). maybe some more experienced chdk source code warriors can share their experience in this matter!? when is enough enough?

hm, get_ready was just a first idea, get_shooting is better, yes. i would like to leave the "get_" in front, as a way to show people that you can only GET a result, not SET something. dont wanna really break the syntax here.

i added the ubasic_camera_sleep(rand()%10); to change the tickcount in a semirandom way (which in turn is a seed for the random function), because the way it is now, in ubasic a command is executed every 10 ms, which means tickcount is incremented by 10 each time you execute random, which is not a good seed. on the other hand, i really am not a good mathematician (although i should be...), nor a good coder and friend of algorithms (although i should be), so please suggest better random functions. we dont really need a "real random", but tickcount alone (as seed) just doesnt cut it.

[Jucifer]

If iris isn't separated from nd, the values should range up to 3: there are also cameras with iris, but without nd.
I already separated iris from nd, changed get_ready to get_shooting.

What do you think, could we use the x=get_nd_present syntax instead of get_nd_present x? That way one could do

Code: [Select]

if get_nd_present=1 then do something
instead of

Code: [Select]

get_nd_present n
if n=1 then do something
.

In Lua you would do the former, that is

Code: [Select]

if get_nd_present() then do something end
.

Hm. I would like to remove the get_ from these, too. :]
I'll likely make a new build today.

[PhyrePhoX]

If iris isn't separated from nd, the values should range up to 3: there are also cameras with iris, but without nd.

well, if get_nd_present returns 0, this means there is no ND present BUT iris is present.to my knowledge there are only three states: nd without iris, nd with iris, no nd with iris.
hm, you really wanna remove the get?

[Jucifer]

if get_nd_present returns 0, this means there is no ND present BUT iris is present

Hm. You're right. :]

Don't know about the get_. But I'd really like to change the syntax. I don't like using intermediary variables. On the other hand, I don't know if I'll ever need these commands, but still. :] New get-type commands (commands, that don't need parameters, only return a value that can be put into a variable) are also easier to add that way, I think.

[PhyrePhoX]

hm, i dont know how to change the syntax of ubasic, do you have an idea?

[Jucifer]

e.g. get_tick_count has only this in ubasic.c:

Code: [Select]

case TOKENIZER_GET_TICK_COUNT:
    accept(TOKENIZER_GET_TICK_COUNT);
    r = shooting_get_tick_count();     
   break;
.
This returns a value, which can be used "as-is" or put to a variable

(versus

Code: [Select]

  case TOKENIZER_GET_ND_PRESENT:
          get_nd_present_statement();
     break;
plus

Code: [Select]

static void   get_nd_present_statement()
{
<snip>
}
)

[PhyrePhoX]

hm, did you test this? if this works, i'm fine with that!
will have no time this weekend though, maybe you can do it

note to self:
add ubasic command to get presence of extra video button (s-series)
next note: add option display BATTERY only in playback (useful for lenghty slideshows maybe)

[Jucifer]

Also, what I'd _really_ like to do is to change the behavior of every "get" command to (x=)command. I think it would make those commands a bit more versatile, but it would also break almost every ubasic script. :] (Scripts wouldn't need much tweaking, though.)

(I just might do it for my next build... *evil laughter*)



P.S. Oops, I did it.

:]