the current implementation of scripting:

mixer loop:
- action processing in a function
- first processing of explicit actions (including actions to add script actions bound to channels)
- loop for every one current script action (so one action can change the time and imply another one)

There is no guarantee for script commands belonging to different time sources to be executed in the wanted order when things come close.
Hopefully the order of actions belonging to the same channel is preserved.

Anyway: Be careful of the implications when you write complex scripts on many channels manipulating each other. At least _something_ will happen. Problably that what you wanted.

You're allowed to seek, but this is seek-on-play (with mpg123_input). No load or socket (close, getstat...) stuff at the moment and maybe never. Most stuff is OK.
List of commands that are not allowed:

addin
addout
close
fadeout
follow
load
nofollow
outload
outplay
play
remin
remout


This list may or may not change. Not all of these commands impose technical problems when scripted, but some do, some make no sense, for others I just didn't feel like it.


script storage: inside channels (general base channel class), global vector containing pointers to objects with script actions on them.


***********
* History *
***********

Now - despite the promise to myself - I'm thinking about the scripting before the first beta...

Scripting syntax only for inchannels; that is what makes sense to me here...
output could follow...
does general scripting make sense? sleep after seconds... start action sometime?
Dunno. But inchannel scripting makes sense for sure.

syntax:

script <chan> <time> <action> <parameters>

maps to 

action
{
	type = IN_SCRIPT
	ints = (chan, action type, int parameters);
	floats = (time, float parameters)
	sb = ...
}

this is put in an vector belonging to inchannel;

for speediness one should keep some kind of info if and on which channels actions are pending; since the normal case is having no script actions; the overhead should reduce to checking a simple condition (bool) on every loop.

Also I only allow scripting for a loaded track; actual processing only taking place if it is playing (so, the script action processing should take place after the normal action processing, so that a 

script 1 0 speed 2 3

(set speed on channel 2 to 3 when channel 1 reaches position 0)

is in effect as soon as needed (although in the case of time 0 one could argue if it should have been already carried out).
Additionally, a seek over some scripted positions should delete the actions (or trigger them?).

Time has the meaning of it being withing the upcoming chunk...

The integration comes to my mind: before the real action loop, the script pipelines are checked and when it is time, the actions are just appended to the global actions list.
Bear in mind that the associated channel is just the timing source; I keep all parameters of the command including channel... so, one could use some dummy channel just for timing? For overall time, the standard output channel saves that purpose nicely.

So, I need outscript and maybe in future timescript for realtime scripting (need subsecond time())...

Hm... how deep is the relationship between script action and channel?

1. know what time to check / play status
2. delete action when deleting channel
...

but keep track of them globally w/o searchting through all channels -> vectors in channels and global vector:

(	*channelwithscript1, *channelwithscript2, ...)

So, when a channel is deleted, its scriptactions are deleted with it and one has to wipe it out of the scriptvector.

Question is: Divide this between in and outchannels or create an abstract channel class from which these are derived? First one is qick and dirty with less changing of code, second one would be "the right way"(tm).

Well...

One thing to note regarding the interface: There is no order to expect in actions taking place during the same chunk but from different time sources; only actions belonging to the same channel keep the order time/when given, so:

speed 0 1
speed 1 1
start 0
start 1
script 0 123.4 <action1>
script 0 23.1 <action2>
script 1 123.4 <action3>

would result in action sequence action2, action1 action3 or action2, action3, action1. I won't promise that the implementation prefers any of these possibilities.


BIG FAT PROBLEM: How to time correctly?

Situation: track loaded  on channel, pausing/stopped at position X. Command waiting to take place in the chunk X is in. Start command from socketeer... before action loop, the channel is paused/stopped - script action not active. But it should be. Looks like there is the need for first execute the normal actions and then think about the script. I see the action processing loop in a function which is possibly called twice.
Yes...


The (in)channel's action vector
-----------------------------

- times in samples (need loaded track, then...) or seconds?
- sorted?

since when there is the granularity of the mixer buffer size, at least the order of events should be preserved AND


Actions
-------

Any stuff that could take too much time or may not succeed  (load, seek) is dangerours an complicates things. I leave these explicit with the waiting and notifying socketeer.

Only simple things:

notify (the client)
volume
eq
speed
pause
stop
seek (only seek-at-play)
eq

All actions stay there when track ends or is loaded... until they find their time or channel is deleted.
