I’m working on a new knob for the Beast DAW, with bidirectional and unidirectional modes, for e.g. panning and volume.
The updates may only use “transform:rotate(angle)” CSS statements to utilize GPU acceleration during automation.
Sadly, Chrome/Electron cannot compose inside an SVG, so I have some nasty splitting and layering of the #SVG elements going on, to apply only one transform per SVG.
Here is an animated GIF: https://social.tchncs.de/@timj/104275988982564877
I must be missing something…
At those prices, why don’t people simply use cheap vServers?
I.e. I just migrated testbit.eu to a new vServer last month, 4 cores, 8GB RAM, 100GB SSD for 5€, a linux-vserver at strato.de.
Would be interested in this, too. I can see a few reasons, but would be cool to know if they are true or if something else is the reason:
For everyone looking for more accounts to follow, there also is trunk.
People can ask to be listed under a specific topic to be more easily found by others with similar interests.
Great idea, I’ve started following accounts posted here and many look quite interesting.
I’m mostly posting about FLOSS and the Beast DAW that I’m developing:
For my homepage and blog, I’m using a moderately sized Python program that generates content snippets as HTML via pandoc2 from markdown files, because pandoc is the best markdown processor out there by a huge margin, I can even typeset formulas via embedded latex and Mathjax with it… The config file is also a hand full of Python lines. With jinja2 templates, the HTML snippets are combined to form blog entry pages or regular pages. I also wrote jinja2 templates to generate RSS2 and Atom feeds (ca 50 lines each) and 11 lines of template code to generate a sitemap, turns out jinja2 is really productive once you get the hang of it…
So far I’ve been too lazy to polish this up and release it, mostly because there are so many static site generators out there already, that another one is probably not badly needed by someone else than me ;-)
In general, I’m busy with re-creating a DAW GUI in Electron that was formerly written in Gtk2.
Currently I’m working on the new preferences dialog:
Electron based Beast Preferences Dialog
We’ve hit a dead-end with our Gtk based UI code.
So now the UI components are developed with Vue instead - the development tooling for web technologies is inexpressibly better and more fun.
Really curious and interested in what kind of a dead-end you’ve hit with Gtk — would there be a chance I could ask you to elaborate some more on that?
Honestly, I have a hard time to figure where to start ;-)
So I’ll just list a few points that come to mind at random:
<input type="range" :min="min" :max="max" :step="steps()" :title="tooltip" v-model="value" onfocus="blur()"/>
span.style.setProperty ('transform', 'translateX(' + Math.round (newlevel) + 'px)');
The above is not a comprehensive list of issues, and doesn’t even touch on the complications of dealing with a project that’s adopting the GNOME philosophy of feature minimalism and ignoring user feedback. The bottom line is, no native toolkit has as broad support and is as future-proof as web technologies have become. Looking back, and projecting forward, compatibility for HTML, CSS and JS look way better than Gtk or Qt API and language support. The web APIs are also becoming much more expressive than native toolkits these days, which means an order of magnitude lesser developer involvement for creating any particular UI.
I migrated text file notes into a local MediaWiki instance on my laptop several years ago, that was fun at first, but I grew unhappy with the editing process being too slow. At some point I moved the contents with the help of pandoc into gitit (Markdown files kept in a Git repo with a MediaWiki like interface). That allowed occasional edits through the console and proper history management (e.g. reverting on squashing edits).
I was still unhappy with the inconvenience of editing text in a web browser and increasingly missed the editing facilities I have with running emacs in a terminal. So I switched the setup once more.
I’m now using a simple Python script that uses asciidoctor (or pandoc) to render md or adoc files from a Git repo as HTML and serves that at a localhost port for FF or Chrome. It adds an invisible one-liner ‘…/page?edit’ link element at the end of each HTML page (with an accesskey=“e”) that triggers the Python script to start up a terminal window with emacs and the md/adoc source of the page I’m currently browsing. Emacs is using git-auto-commit mode for the Git repo directory.
Put together, that means I can browse through my Git repo in a Wiki-like fashion and at the press of Shift+Alt+e get an emacs terminal window right into the current document where edits are auto-tracked in Git.
Interaction is instant and this combines all the benefits of wiki browsing, Git and text editing through emacs for me.
I was running a gitit installation as a daemon on my laptop for years, set it up initially for my software engineering studies at TU Vienna, but eventually dropped out and stopped using gitit. Gitit is/would be nice - but isn’t maintained a lot, notably by pandoc developing further than gitit - but there are still sometimes contributions.
Today I’d probably go with something that integrates with emacs, provides a nice web/mobile/kindle-view and has good search capabilities.
At some point I’ve setup a blog with Ikiwiki, but I really can’t recommend this tool.
This week I’m trying to port the autotool machinery of the rapicorn project to meson and ninja to allow faster builds.
So far build times seem to be promising (though I’ve already been using ccache previously), but in particular the vastly improved configure times seem to be making things worthwhile.
I’m bringing my automated package builds up to speed, using only free infrastructure.
Push commits to github -> triggers travis-ci builds
travis-ci sets up a Docker environment to build deb packages
Upload readily built packages to bintray.
The first project works at this point: https://github.com/tim-janik/rapicorn/
The second depends on the first and still needs work: https://github.com/tim-janik/beast/
Because the raw travis-ci environment is notoriously hard to debug, I’ve previously used pbuilder for the packages, but that’s still hard to deal with. Docker makes all this a breeze, it abstracts from the travis-ci tools and allows easy local rebuilds in case of failures. Also, simply exchanging the FROM line in the Dockerfile allows to trigger package builds for multiple distributions. bintray takes care of the package indexing and provides download space, so I can pass users a simple apt source line to test out development packages freshly built from source code that’s just been pushed 20 minutes ago.
We are revisiting versioning schemes for a GUI library and an audio synthesizer.
Versioning ties in with package names in distributions, ABI guarantees, API breakage, versioned binary names to allow parallel installations of multiple releases and whatnot…
And googeling on the net turns up a million contradictive opinions, from semver.org to “always use dates”.
Here is our current take on things, comments welcome: https://groups.google.com/forum/#!topic/rapicorn/M69DlAx61YE
Working on porting the object system in BEAST (music synthesis app) from GObject to IDL-based C++ classes. Quite laborious, given that an object system is ingrained so deeply into an app and library.
But it’ll definitely be worth it once completed and allow new scripting facilities and a badly needed renovation of the GUI to match state of the art DAWs. I’ve summarized the beginning of the efforts in a recent DevLog: https://testbit.eu/rapicorn-idl-moving-into-beast/
I should have worked on a new Rapicorn release but instead cooked up a new IPC binding implementation. In the process I needed to use thread-local storage and did some benchmarking around TLS while I was at it. I’ve blogged about it here: