st.experimental_audio_input#9404
Conversation
| const [recordPlugin, setRecordPlugin] = useState<RecordPlugin | null>(null) | ||
| // to eventually show the user the available audio devices | ||
| // eslint-disable-next-line @typescript-eslint/no-unused-vars | ||
| const [availableAudioDevices, setAvailableAudioDevices] = useState< |
Check notice
Code scanning / CodeQL
Unused variable, import, function or class
| *, # keyword-only arguments: | ||
| disabled: bool = False, | ||
| label_visibility: LabelVisibility = "visible", | ||
| ) -> UploadedFile | None: |
There was a problem hiding this comment.
we unfortunately do not handle this consistently across widgets, but I want to highlight that using a Streamlit-defined type might not be the best UX because the developer sees the type, but has to click on it to get what it really means and we discourage developers to import it from here because we don't give any guarantees about our internal package structure.
I believe we should move all of our type definitions into a module streamlit.types or similar and make that an official part of our API (guarantee the existence) at some point. Until then, it might be nicer to duplicate the definition for the publicly exposed API here and write Union[UploadedFile, DeletedFile, None] (although also here two Streamlit-types are part of, so probably not worth it 😅)
No immediate action item for this PR, but wanted to share one inconsistency in our codebase right now so that we can all think about it 🙂
There was a problem hiding this comment.
@raethlein I definitely agree that types as part of Streamlit API is a great idea!
We need to think carefully about exact types (especially for file-uploader, data-editor like widgets). But on the strategic level, it is something we should do at some point!
d0936b0 to
763dc23
Compare
d7b5d0c to
e51d334
Compare
lukasmasuch
left a comment
There was a problem hiding this comment.
Great implementation & feature 🚀 it looks almost ready for me, I have a couple comments on testing and some observations here:
The responsiveness of the widget seems to be quite good. The case where it doesn't work well is when it is missing the microphone permission (maybe the StyledWaveformContainerDiv needs an overflow: hidden?):
Another observation: clicking on start recording - if there is already an old recording - triggers a rerun. This rerun seems to be a bit unnecessary. Is this expected?
Screen.Recording.2024-09-13.at.22.49.03.mov
A strange observation: changing the theme via the menu seems to consistently cause some trouble with the placing of the waves:
@lukasmasuch the reason the rerun is happening is because its deleting the old file before recording the new. perhaps we should not do that to avoid this rerun? |
Hmm, yeah it looks like we don't need to delete the file / rerun up until the point where the new recording is available (on stop recording)? Two potential options:
Clicking the clear button might be the only case where we want to delete the file & |
i've switched it to follow this suggestion |
d650c77 to
b52963b
Compare
3274b81 to
1547acb
Compare
## Describe your changes Rename `st.audio_input` to `st.experimental_audio_input` ## GitHub Issue Link (if applicable) ## Testing Plan - Explanation of why no additional tests are needed - Unit Tests (JS and/or Python) - E2E Tests - Any manual testing needed? --- **Contribution License Agreement** By submitting this pull request you agree that all contributions to this project are made under the Apache 2.0 license.
d444bf9 to
71c6c6e
Compare
sfc-gh-kmcgrady
left a comment
There was a problem hiding this comment.
Protobuf is backwards-compatible
| message AudioInput { | ||
| string id = 1; | ||
| string label = 2; | ||
| string help = 3; | ||
| string form_id = 4; | ||
| bool disabled = 5; | ||
| LabelVisibilityMessage label_visibility = 6; |
There was a problem hiding this comment.
I think this is another aspect we should codify: whether or not to use optional I think we use it pretty inconsistently 😅
## Describe your changes 🔉 This PR introduces the `st.experimental_audio_input` widget! 🎤 ### Light Theme Demo  ### Dark Theme Demo  ### Light Theme No Mic Permissions <img width="755" alt="image" src="https://github.com/user-attachments/assets/51df40c7-1c75-415b-bc70-59fdb59f1c3b"> ### Dark Theme No Mic Permissions <img width="752" alt="image" src="https://github.com/user-attachments/assets/8f8d47f6-2195-4dfc-ab41-07231ae3a15b"> Note: this currently does not work on safari and by extension iOS so users on that platform will see a warning with the audio_input disabled  ## GitHub Issue Link (if applicable) streamlit#8899 streamlit#903 ## Testing Plan - Unit Tests (JS and/or Python) - python unit tests added ✅ - E2E Tests - e2e tests added ✅ - Note: was unable to reliably add invalid permissions check test that would work locally - Any manual testing needed? - was also tested manually and will be QA'd --- **Contribution License Agreement** By submitting this pull request you agree that all contributions to this project are made under the Apache 2.0 license. --------- Co-authored-by: Karen Javadyan <kajarenc@gmail.com> Co-authored-by: Bob Nisco <bob.nisco@snowflake.com>
Describe your changes
🔉 This PR introduces the
st.experimental_audio_inputwidget! 🎤Light Theme Demo
Dark Theme Demo
Light Theme No Mic Permissions
Dark Theme No Mic Permissions
Note: this currently does not work on safari and by extension iOS so users on that platform will see a warning with the audio_input disabled

GitHub Issue Link (if applicable)
#8899
#903
Testing Plan
Contribution License Agreement
By submitting this pull request you agree that all contributions to this project are made under the Apache 2.0 license.