New plugin - WaveDrom

andrewg_oz · September 25, 2025, 4:54pm

I have just released a plugin for WaveDrom.

WaveDrom is a renderer for timing diagrams, waveforms and logic circuits. I did not write it, but I have wanted to integrate it into TiddlyWiki for some time…

This new plugin can be found on my TiddlyWiki (along with all the other plugins I’ve developed):

Scott_Sauyet · September 25, 2025, 5:17pm

It looks very nice! I don’t really know what the diagrams are for, and the WaveDrom site seems to assume that we already understand that. But it does look good!

pmario · September 25, 2025, 8:50pm

Cool stuff I wish I would have had something like this in 1988.

We did draw that stuff with pen and paper. – Paper doesn’t blush. The problem was that our “theoretical” drawings differed quite a bit from the “practical” measurements. So the eraser was our best friend, to “align” theory with reality

nemo · September 26, 2025, 2:40am

that looks neat, but I’m seeing a bug: I looked at the examples in the WaveDrom tid, switched to edit mode to see how it was handled, then cancelled the edit and the examples are no longer rendering. They only come back by closing and reopening the WaveDrom tid.

2025-09-26T12:38:23_e136f9e2

TW_Tones · September 26, 2025, 3:43am

Very interesting @andrewg_oz and thanks for your contributions. I am not sure I will need to use this however very happy that I could if needed, who knows as I start to write a non-fiction book.

A couple of friendly suggestions

Your brand name is a bit long, I abbreviate mine to PSaT as in $:/plugin/PSaT/… asdo many others.
Using blue in your charts look like clickable links, in blue, when they are not.

Community contributions

You have being able to demonstrate a range of solutions, code libraries that you adapted for tiddlywiki. I have long sought to have this documented at a high level so others have some steps to take to intergrate other open source solutions in tiddlywiki.

There are dozens if not thousands of open source projects out there that tiddlywiki users may want to leverage but also those projects may appreciate TiddlyWiki as an easy way to demonstrate their project and provide a sand box. However I have not found any guidence out there.

I approached a few such projects but had no guidence to give them and got ignored even although it would have being mutualy benificial.

If you fancied providing a general overview, of intergrating such solutions in TiddlyWiki, I would be happy to write a component on why the approach is needed, and the benifits of it sitting on top of tiddlywiki. Outsiders take a while to grasp how tiddlywiki maintains its dynamic nature, that is how changes propergate through out.

There are also mechanisiums in tiddlywiki which some of these projects could utilise with an understanding of tiddlywiki, but they need to be motivated to look closer.

andrewg_oz · September 28, 2025, 12:33pm

That’s a result of what I consider to be a design flaw in their library:

github.com/wavedrom/wavedrom

Purpose of notFirstSignal in Code Base

opened 04:40AM - 27 Nov 23 UTC

Ganesh-AT

Aliaksei @drom , I have been primarily using WaveDrom through the WaveDromEdi…tor browser interface. I am quite familiar with major portions of the code base for both WaveDrom and wavedrom.github.io, but I realized yesterday that there are some segments that are utilized in workflows that I am not used to. While working on a proper fix for the PR submitted in #362, I found something that I would like more clarity on. I see a ```notFirstSignal``` boolean variable that is passed from ```ProcessAll``` in ```process-all.js``` all the way down to ```insertSVGTemplate``` in ```insert-svg-template.js```. Its sole purpose seems to be the avoid repeating the style and defs sections for the second SVG onwards (when there are multiple WaveDrom type scripts on the same page). Multiple SVGs are being rendered in distinct divs with different IDs. In that case, can you shed light on why the style and defs are not being embedded into each SVG? I am planning to do away with that variable in my fork (but I still want my fork to be compliant with anything accepted by WaveDrom). Is there any other use for ```notFirstSignal``` in some other workflow that I am not considering here? As I mentioned in my comment in #362, WaveDrom doesn't render multiple SVGs with different skins on the same page correctly. I reported this back in 2019 in #263, albeit for a different use-case (editing outputs in Inkscape). Over the years, I have made many changes in my fork, and one of them was mass-renaming of the id of all elements in all skins to follow the pattern : ```'wd_<skin-name>_<original-id>'``` (that was also instrumental in validating all SVG outputs as compliant - resolving #323). One of the advantages of doing this was that I could have multiple skins in the same diagram. Prior to yesterday, I had never actively tried the 'multiple WaveDrom WaveJS scripts in a single HTML page' input. In preparing a solution for #362, I am testing out multiple multi-skin WaveJS inputs in a single page. The basic test case is the first SVG with default skin, and the second one with narrow skin. After disabling the ```notFirstSignal``` feature, I was able to get the style and defs in each SVG separately, but the lane parameters for the narrow waveform was from the default one. After commenting out the logic based on the ```index``` parameter in the ```laneParamsFromSkin``` function of ```render-signal.js```, I was able to get the rendering of all diagrams on the page correctly. Do you foresee any issues for workflows that I have not considered due to the following changes? <details><summary>process-all.js (Line 24 onwards)</summary><p> ``` js let notFirstSignal = false; for (let i = 0; i < index; i += 1) { const obj = eva('InputJSON_' + i); renderWaveForm(i, obj, 'WaveDrom_Display_', notFirstSignal); //if (obj && obj.signal && !notFirstSignal) { // notFirstSignal = true; //} appendSaveAsDialog(i, 'WaveDrom_Display_', document.getElementById('InputJSON_' + i).innerHTML); } ``` </p></details> <details><summary>render-signal.js (Line 13 onwards)</summary><p> ``` js function laneParamsFromSkin (index, source, lane, waveSkin) { //if (index !== 0) { // return; //} const waveSkinNames = Object.keys(waveSkin); ``` </p></details>

I have just uploaded an updated plugin that resolves this by inserting the rendered graphic into tiddlywiki using an img element with a data: URL.

I had hoped to include a way of enabling a custom stylesheet to be inserted into the generated SVG, but cannot figure out how to get TiddlyWiki to “execute” the macros in a tiddler on demand so I can insert the result into the SVG. In short, I have a stylesheet tiddler that uses <<colour>> macros, but I can’t work out how to get tiddlywiki to turn them into their result, such as #112233.

andrewg_oz · September 28, 2025, 12:46pm

I’ve found the convention of reverse domain names as used by the various app stores to be a good one to help prevent future name collisions. I can’t see the benefit of a shorter name.
Yes, blue is not a good colour, but it’s the default in the library. I’m trying to work out a way to restyle the colours, ideally using the tiddlywiki <<colour>> macro to make use of the selected palette. More details in my prior post.

TW_Tones · September 28, 2025, 11:13pm

Tiddlers that contain styles have the stylesheet tag but also some have the type field set. stylesheet tiddlers that contain tiddlywiki script will not be evaluated with type set. removing the type field will default blank/tiddlywiki and macros should be evaluated.

transclusion results in wikification but honors the type field.

I hope that helps @andrewg_oz

andrewg_oz · September 29, 2025, 3:31pm

I needed the macros executed using JavaScript, i.e. $tw.wiki.renderTiddler(). However, I’ve “brute-forced” things by doing the <<colour>> macro by hand. The result is quite satisfactory.

I’ve now uploaded an updated version of the plugin that mostly adapts to the selected TiddlyWiki palette. That resolves the blue text that looked like links.

andrewg_oz · September 30, 2025, 3:50pm

I find that my TiddlyWiki development method is often “try random things until it looks good”. I make liberal use of the debugger to inspect internal objects and data structures and step through the code to watch what it does. It’s not a workflow that’s easy to describe or welcoming to third-party library developers.

I will consider writing up something in my TiddlyWiki. It would be useful for future me in any case.

HistoryBuff · September 30, 2025, 5:19pm

Oooh! I like this! This could come in very handy for some of my hobby electronics products. If only I had had this prior to retirement!

andrewg_oz · October 8, 2025, 1:58pm

I have updated this plugin. I discovered that while the GitHub examples referred to v3.1.0 files, the most recent version is v3.5.0. My plugin is now using that code.

I have also added some extra examples in my TW showing apparently undocumented diagram types.