DarienBrito
commented
3 years ago Hi Eric,
Thank you for your ideas!
It would be amazing if the local timings could be variable be stored and invoked per preset. It seems like it should be possible with how you've created the local timing, but it seems to not store in the preset. That way you could get those nice split time fades in the global scene launcher
This would be possible indeed, although I am not sure I would have it like that by default, since local behaviour is meant to be a form of bypass of the global behaviours so that one can always flexibily change things locally without worrying about changing desired values on that level. Perhaps I'll add a mode for this, so users can choose the default behaviour.
With the scene launcher, it is already excellent, but a few thoughts on some things that may be improvements. It seems like it would be helpful to be able to have multiple preset managers be able to be associated with a single cue stack. That is to say, cue1 will fire preset1 on engines 1 and 2, cue 2 will fire preset2 on stack 2, etc etc. that way you could isolate your automations a bit. Break your show into more manageable chunks without requiring putting too many variables into one preset manager or needing multiple SceneLaunchers.
You can already do this if you use the scripting option for the scene launcher (there is a toggle that enables scripting in the options). You simply need to write a script per scene that triggers the PresetManagers you want. That will give you the most flexibility and allow you to easily do what you describe.
Stacks of PresetManagers is nonetheless an interesting idea, so I will consider that for the next revision.
Again with the scene launcher, it seems like you're close again to this with the delay function. It would be great if up-time, down-time, up-delay, and down-delay were all addressable, similar to a lighting console. I understand it becomes a bit tricky defining what 'up' and 'down' are in the context of parametric animations, but maybe it could be a checkbox?
I am not familiar with light consoles so I am not sure what you mean by this?
Finally, and maybe the easiest request. Maybe some standardized OSC callbacks internally for scene transport/navigation? say preset1/fire or scene1/fire to fire the scenes from an cueing engine (say QLab)?
OSC commands beyond TDMorph's MIDI/OSC auto-learning system must be created by the user. So you can have a OSC DAT for instance that listents to those commands and trigger the SceneLauncher. You can control all the transport navigation via code already, although I think I did not expose everything for the user on a high level. Will look into that for the next update ;)
Hi Darien!
TD morph is really awesome! I have some questions that may have answers or may be enhancement requests.
It would be amazing if the local timings could be variable be stored and invoked per preset. It seems like it should be possible with how you've created the local timing, but it seems to not store in the preset. That way you could get those nice split time fades in the global scene launcher
With the scene launcher, it is already excellent, but a few thoughts on some things that may be improvements. It seems like it would be helpful to be able to have multiple preset managers be able to be associated with a single cue stack. That is to say, cue1 will fire preset1 on engines 1 and 2, cue 2 will fire preset2 on stack 2, etc etc. that way you could isolate your automations a bit. Break your show into more manageable chunks without requiring putting too many variables into one preset manager or needing multiple SceneLaunchers.
Again with the scene launcher, it seems like you're close again to this with the delay function. It would be great if up-time, down-time, up-delay, and down-delay were all addressable, similar to a lighting console. I understand it becomes a bit tricky defining what 'up' and 'down' are in the context of parametric animations, but maybe it could be a checkbox?
Finally, and maybe the easiest request. Maybe some standardized OSC callbacks internally for scene transport/navigation? say preset1/fire or scene1/fire to fire the scenes from an cueing engine (say QLab)?
Looking forward to hearing your thoughts on some of the above All the best, Eric