may 1 2017

///////////////////
REMINDERS

• in Conductor, need to set "all active" AND "pass all".

• when building app, make sure at least one sub patcher is inside, otherwise those
objects don’t get compiled.

• Soundflower routing
MultiBot 
	64 ch output (1 & 2)=>
ListenBOT 
	=> 64 ch input
LivePerformerBOT 
	=> 2 ch input
	64 ch output=> 
Live 
	=> 64 chan (3&4) input
Kontakt 
	=> 2 ch input

SoundFlowerBed 
	=> 64 chan NONE; 
	2 chan “Build In Output

• needs at least TWO instances in ensemble to play
	- selecting bands based upon other bot’s bands [v currentActiveBands]

• Play styles in poly (Drony)
	> delay is a range (0-1) based on vitality
		- Londyn
			- section length 
		- Milan
			- phrase length (4 beats @ tempo * phraselength (4))
		- Siena
			- beat @ tempo (isn’t rhythmic, because beat scaled by value (0.-1.)
	> “phrase” is determined by impatience/persistence (inactive) switch

///////////////////
TO DO

• are Bots sending out ACTUAL activeBands, or only the ones that they 
originally proposed (before playing in section)?

• WHY ARE BOTS GENERATING MORE SECTIONS THAN THERE ARE?
	- RezNoizBots do NOT erase old data! If new composition has fewer sections,
	those overwrite what RezNoizBots have, but they still think there are the 
	extra sections...

• in preparation for a liveaudioBot, make these more responsive to ListenBot
	- not just a filter. Maybe Siena can react faster to activeBands that 
change?

• Data from ListenerBOT doesn't change how RezNoizBOTs behave, only placing a 
filter on their output.

//////////////////
CHANGES

- changed [trigger_notes]: poly Drony (get_pitch): 
	play across this section's...
- changed [determine_all_barkBands]
	lots of changes
- changed [calculate_section_pitches]
	single (right) inlet
	fixed shift_activeBands_amount
- added [p join_section] and moved things from [play_in_this_section?] into it
	if agent joins section, needs to calculate barkBands and pitches
- fixed [p broadcast_activeBands]
	didn't send if 1st section's band was zero

//////////////////
QUESTIONS 

activeBands *should* be timbral, but it is interpreted as pitchrange.
	how should agent adjust timbre if this param is used for pitch?

//////////////////
FURTHER REMINDERS

When Conductor stops, ParamBot sends compositionDone message
	- this will reset and clear most data in this musebot (AND ParamBOT).

After newComposition is sent, Conductor waits for data from PCsetBOT and
ParamBOT, then starts on its own.

@newComposition, 
	- [determine_sections_to_play] 
		selects sections to play
	- [determine_all_barkBands]
 		selects active band for each section (no negotiation)
		these are expanded based upon compliance
		stored in [dict myActiveBands]
	- [calculate_section_pitches
 		select pitches (!) based upon myActiveBands
		takes into account other agents bands, 
 			will adjust pitch selection AND update myActiveBands

@newSection
	- if agent isn't active in section, but changes its mind (i.e. not other agents active)
		> turns on matrix display
		> calculates new activeBands (no negotiation)
		> calculates new pitches (with negotiation)

• arousal (ParamBot)
	- with vitality: add extra voice
	- with vitality: inter-onset delay between notes
• valance (ParamBot)
	- with arousal: voice density
• compliance (internal)
	- how wide the backbend range is
	- whether it will add a section if not already playing
• consistency (internal)
	- how close band will be to previous band in previous section
		* low consistency will “allow” bot to change bands between sections *
• vitality (internal)q
	- how many sections to be active in
	* scaled by compliance *
	- whether it can add a section if not already playing
• repose
	- play in active or quiet sections?
		- the higher the repose, the more the agent prefers sections with lower activity levels


note duration: based upon vitality (internal) and arousal (external): 
low product = longer note duration 

playing across sections dependent upon consistency (internal): 
high consistency = more cross section durations

• impatience: how willing is agent to become active
• persistence: how willing is agent to remain active
• vitality: how much an agent is willing to do once active (hdensity)
• consistency: how often agent will vary its playing
• compliance: how strict will it interpret requests