Hi Jeremy, thanks for the detailed response.
I do know about the timer tools by Eric Shulman-I'm using one of the action widgets from that package, and it makes my life a lot easier. I managed to get a rudimentary version of audio working-it's a startup module that can play base64-encoded tiddlers when it receives a message, as you suggested. A quick question though-is there a difference between adding message listeners to $tw.wiki and $tw.rootWidget? I'm presuming $tw.wiki is for things which are more global in scope, handling messages related to the browser and such, but I'm not sure if there's a functional distinction or just a semantic one. With regards to audio in the core-that would be excellent! browsers have support for quite a wide array of audio formats now-WebAudio has DecodeAudioData, which supports everything that the <audio> element does (mp3 and ogg being of specific interest w.r.t. compressibility). For my use case, I don't particularly mind large files, and the audio that I'm using isn't particularly large-it's just alarms, etc.-so I just dropped a base64-encoded wav in. Again, thanks for the advice, I'll be able to take this a lot further now. Dhruv. On Wednesday, September 29, 2021 at 4:02:30 PM UTC+5:30 jeremy...@gmail.com wrote: > Hi Dhruv, > > > I've recently discovered TiddlyWiki and it's excellent. I've always wanted > notes that are somewhat interactive-automatic reminders based on the data I > put in, managing tasks right inside notes etc.-and TW seems to be wonderful > for that sort of thing. > > > Thank you! It's good to hear TiddlyWiki discovery stories. > > to that effect, though, I needed some custom functionality. I'd like to > have timers, where I'd get an audio indication when the timer is done. > > > There may already be plugins that provide this functionality, I think Eric > Shulman has some timer tools, and I hope he'll jump in. > > After reading around for a while, making a custom action widget seems my > best bet-I'd like to use webaudio, and from what I know JS macros don't > allow me access to the DOM. > > > It's correct that JS macros can't access the DOM. > > However, here an action widget may not work either. > > What I want to know is...is there a way to have persistent data inside > widgets, such that an expensive computation only takes place once, perhaps > when the wiki starts? > > > No, instances of widgets are ephemeral: they are destroyed and rebuilt as > the refresh process proceeds. Only the tiddler store can be used for > storing state data by widgets. > > right now I'm planning to store sound files as base64-encoded data, either > inside the widget directly or as a tiddler (somewhat ugly, to be sure, but > it seems like the most portable solution) and decoding this data into an > audio buffer would take non-negligible time. I would prefer not having to > create an audio buffer each refresh cycle. > > > Not ugly at all: TiddlyWiki handles images the same way, and it works > surprisingly well with modern browsers. > > More fundamentally...my question is-do widgets get recreated every refresh > cycle? or do they only get created once, perhaps when wikification happens, > and then they just have refresh called on them? > > > The lifecycle of a widget is that it gets created, refreshed zero or more > times, and then destroyed. Many widgets do indeed cache information in the > widget object instance, but... > > (Maybe a startup plugin would work well for this, too. I'm not quite > sure-I've read quite too much in the past few days, without having enough > actual experience to turn all my knowledge into a working product.) > > > ...Yes – anything more substantial is better handled via a "daemon": a > long lived, global JavaScript object instance to which widgets send > messages. In TiddlyWiki, daemons are packaged as startup modules. > > Here, it sounds like a "tm-play-sound" message with a parameter indicating > the tiddler containing the sound sample to play would be a reasonable > starting point. > > I don't know if there's any prior work on audio in TiddlyWiki, but I'd > certainly be interested in improving core support. The blocker in the past > was always that browsers could only capture audio in enormous WAV format, > but by now perhaps they can capture straight to compressed MP3. > > Best wishes > > Jeremy > > > Thanks, > Dhruv > > -- > You received this message because you are subscribed to the Google Groups > "TiddlyWiki" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to tiddlywiki+...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/tiddlywiki/da4533d4-6e49-4205-8aec-bc585c6a89e1n%40googlegroups.com > > <https://groups.google.com/d/msgid/tiddlywiki/da4533d4-6e49-4205-8aec-bc585c6a89e1n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/38487ac1-c6e0-4f2f-8ef4-db97fc9c22e9n%40googlegroups.com.