I continue to improve the CLAP support in Anklang, it can already load and process plugins with CLAP support (though most of them are in beta). Currently I’m at the parameter support, so Anklang gets to display, load and save plugin parameters.
Here are examples of some nightly versions that support CLAP:
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.
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:
you can have longer running contracts for your servers at AWS (e.g. 1 year) and then get a discount, but if you only need a simple server still more expensive than other options
our cheap examples seem Germany-based (strato for you, Hetzner for me); maybe the US server market is more expensive
some developers might only know AWS/Google Cloud and just use that because everybody uses that
some people might need the scalability and some things are easier with AWS/Google in that case (you can define which servers should be located in the same data center, and you get a private subnet automatically; if you use non-cloud vservers you have to setup the VPN yourself)
some people might need the scale-out to different regions in the world (but that’s also possible with smaller companies, e.g. even in the small country of Austria there is a hosting company that provides data centers all around the world)
some people might like the other services that are provided, like SQL database etc. (usually priced by the EC2 instance price + additional price for service)
some people might use it for a part of their infrastructure just to find out how it works and if it is really better
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.
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:
There’s no way we could keep our code base up with Gtk API changes with reasonable effort, just look at the sheer amount of incompatible changes in the last 2 or 3 releases here: https://download.gnome.org/sources/gtk/3.96/gtk-3.96.0.news
While many HTML elements are familiar to developers through website maintenance or other side projects, every Gtk UI component we used had to be learned from scratch, most often from source code because Qt/Gtk components never have the broad online presence/community support/article treatment/etc that HTML elements and CSS have. Most Gtk Widgets requirered fixes for corner cases or reactivity in the toolkit before we could use them reliably.
The Gtk version of Beast still uses Gtk2 and yet has to chase deprecation after deprecation, b/c Gtk2 likes to deprecate stuff despite never going to be able to actually remove API because of its ABI stability guarantees.
There’s no match in the Gtk/Qt world for Firefox’ of Chomre’s devtools and the ease with which the browser devtools allow profiling or playing with the UI components through a JS console.
The new Beast UI develpopments have settled on Vue, there’s no match for that in the Qt/Gtk world either.
One line of reactive Vue template can often replace a whole compilation unit of Gtk widget setup, with signal connections, event processing and and glue code, like:
<input type="range" :min="min" :max="max" :step="steps()" :title="tooltip" v-model="value" onfocus="blur()"/>
Recent CSS versions allow wide ranging styling possibilities for which GtkStyle in Gtk2 has no match and Gtk3 comes with yet another home grown “CSS” version that’d have to be re-learned, isn’t API stable and doesn’t have tooling support like e.g. SCSS.
As a DAW, some UI components have soft realtime requirements, e.g. for displaying volume level updates. To be fast enough for 60fps display, updates have to use GPU compositing without Layouting and CPU rendering being involved. Accomplishing this in Gtk would be a major undertaking in itself, in Chrome/JS this boils down to: 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.
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”.
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:
https://testbit.eu/thread-local-storage-benchmark/
I continue to improve the CLAP support in Anklang, it can already load and process plugins with CLAP support (though most of them are in beta). Currently I’m at the parameter support, so Anklang gets to display, load and save plugin parameters. Here are examples of some nightly versions that support CLAP:
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: @timj@social.tchncs.de
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. That is:
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: https://testbit.eu/thread-local-storage-benchmark/