-
Notifications
You must be signed in to change notification settings - Fork 0
Description
In reference to:
plunk/ap/app4_drill_but_make_it_slabsiter/app4_drill.py

In apply model with live data page:
Note that one can distinguish 3 (maybe 4) functionality categories here. Specification of
- the source (the stream2py stuff)
- the dpp (divided here (and that's a good thing) in preprocessor and model to apply)
- what to do with the output (visualize (and possibly save the viz).
It's sometimes appropriate to have everything in one place like you did.
But sometimes it's better to be able to separate stuff.
Ideally, we'd like to be able to one or the other easily.
For example, could you make a version of this where the source specification is separate.
This means that they'll be an additional page where the user will have all those "input device" etc. fields that they'll set and save under a name, and the "apply model with live data" page will then contain only a "source" field from which this saved live source definition can be selected.
Then, the next step (or you can do it like this directly if you wish):
Now, there's no more need to have a separate "apply model" and "apply model with live data" page.
There can just be an "apply model" page. It's just that either the source is defined to be one (or several? don't know if that's possible yet) wav file, or to be some live source specification that was saved.
There's several ways to do this too -- probably each with their optimal context as well.
I'll let you have a think about whether a single, or several, methods should be toolified for this.
You could:
- merge stores (try using
collection.ChainMapfor example -- though of course, here we can't have key conflicts!) - have the user select first the kind of source (wav files or live source) and then present them with the corresponding store. If possible, use your nested Mapping/stores tools for that!