ristic

My understanding is that Reaper has a more mature feature set in this regard. That said, it is possible to do a number of things in Ardour already using Lua scripts: https://manual.ardour.org/lua-scripting/ and https://github.com/Ardour/ardour/tree/362b9cb4fa4fbacd0660b1...

I wrote some plugins for fun a few years ago in Lua: https://github.com/robsco-git/ardour-plugins

My understanding is that the plugins one writes for Reaper are compiled on the fly so I imagine they offer better performance.

Yep :) https://robsco.info/music/

Language is evolution.

It's a lot more setup but I've had a good experience with redux, redux-persist and localForage. localForage picks the best available browser storage API. One can select which subset of data to persist with redux-persist. It does assume a redux buy in...

Would have been nice if he got around to the router at our office, we got cryptojacked: https://imgur.com/a/Q7Pmxth

Unfortunately, the CALF series have been notorious for having problems or causing crashes in the past. If you do want to try it out, I highly recommend getting the latest version or building from git as a lot of distributions package an older version in their repositories.

Things are slowly getting better if you want to run Windows VSTs under Linux. I found this very interesting as a overview of some of the current possibilities: https://www.youtube.com/watch?v=jsZnSg4DKDU It is a demonstration for a proprietary DAW, Bitwig, but he does talk a lot about Windows plugins under Linux that I imagine applies to Ardour as well.

If you follow the "Ready-to-Run Program" prompts on the official download page[1] as an anonymous or unsubscribed user, you will reach a page that explains their method/philosophy.

I'm sure Paul would be happy to speak to you on IRC (#ardour on Freenode) about successes/failures but of course I can't say this for sure.

Also, I am awaiting a stream of Paul's upcoming talk (as I can't get to France for LAC2017[2]) "20 years of Open Source Audio: Success, Failure and The In-Between"[3]. I hope part of the talk will address the financial aspects that are of interest to you.

[1] https://community.ardour.org/download [2] http://musinf.univ-st-etienne.fr/lac2017GB.html [3] http://musinf.univ-st-etienne.fr/lac2017/lacProgramGB.html

I have built something similar that works with LibreOffice Calc as the backend instead of Google Sheets:

https://github.com/robsco-git/spreadsheet_server

I've recently adopted a similar approach. I have a virtual machine running the same OS and version as the target production machine. I'm using QEMU and connecting to it via ssh.

There are a number of exciting projects in the Linux audio that may be of interest here. I'll just name a few, in no particular order, that have tickled my interest.

setBfree - A DSP Tonewheel Organ emulator. https://github.com/pantherb/setBfree

alvdrums.lv2 - a simple Drum Sample Player Plugin https://github.com/x42/avldrums.lv2

The rest of the x42 suite: http://x42-plugins.com/x42/

The zam-plugins suite: http://www.zamaudio.com/?p=976

giada - your hardcore loop machine https://www.giadamusic.com/

Helm - a great sounding (to me) software synthesizer http://tytel.org/helm/

ZynAddSubFX's new GUI http://zynaddsubfx.sourceforge.net/zyn-fusion.html An amazing software synth even without this new GUI.

Guitarix - a guitar/bass amp and effects modler http://guitarix.org/

Bitwig Studio - A proprietary DAW available on Linux https://www.bitwig.com/en/home.html

u-he plugin suit available on Linux http://www.kvraudio.com/forum/viewtopic.php?t=424953

I'm sure there are a few more that I'm forgetting right now.

That seems like an interesting avenue to peruse. I would imagine you would end up reimplementing a lot of what Calc has already solved. I'm thinking about mapping cells to cell references (A1:C57), how to handle VLOOKUP, sheets etc. If I had to do this, my approach would probably be to take the headless Calc code and strip out the parts that are unnecessary.

I think you may find what you are looking for here: http://download.documentfoundation.org/libreoffice/src/

I don't have any experience working with macros between Excel and Calc. That said I did find some resources that may answer your question. First off: https://help.libreoffice.org/Common/Using_Microsoft_Office_a...

There seems to be at least one tool that can convert macros from Excel to Calc for you: http://www.business-spreadsheets.com/vba2oo.asp Having done no testing, I have no idea how well this will work.

Also, there seems to be a good resource on specifically LibreOffice macros available here: http://www.debugpoint.com/category/programming/libreoffice

I have just updated the example_client and README. Combined they should resolve your suggestion.

Here is the example client: https://github.com/robsco-git/spreadsheet_server/blob/master...

The example_client may help answer your question: https://github.com/robsco-git/spreadsheet_server/blob/master...

I don't quite follow your question but I'll give it a shot. Here is a high level version of how I am currently using the tool: A user is presented with a bunch of input variables on a web page that are then set by the user. These variables are sent to the server and the server sets the relevant cells using spreadsheet_server. Resultant values from other cells are retrieved by spreadsheet_server and then sent back to the web page and presented to the user in the form of a graph or table etc.

Pretty much all of the logic to get from input to output is handled in the spreadsheet by LibreOffice.

I probably need to be more descriptive. The locking is just within Python to prevent simultaneous reads and writes to the spreadsheet messing with expected results. This makes sense for my use case but probably not all use cases.

Currently it simply check for any new spreadsheet(s) in the ./spreadsheets directory and opens them in LO Calc. Any spreadsheet that has been removed will be closed in LO Calc. There currently is not support for what you described. There is potential for that sort of thing to be implemented though...

If you built the front end for it then sure. In its current state this tool just deals with reading and writing cell values.

Yes, it is true that it is running a LO Calc binary.

Not implying that you don't already know, but this may be of interest in terms of Calc/Excel compatibility: https://wiki.documentfoundation.org/Feature_Comparison:_Libr...

I have used the tool predominantly with xlsx format spreadsheets created in Excel.

I've been using it for a fairly specific use case: Creating web applications from business logic that has already implemented in a spreadsheet. So instead of trying to figure out what the spreadsheet is doing (they can get fairly complex and the flow of calculation can be difficult to follow) I just treat it as a black box. Input some values here and read the resultant values from somewhere else. Integration with flask/django and you have a prototype within a day.

Great, I'll have to take a look into their solution to see if I can learn or improve anything. Thanks for the heads up.

For anyone interested, I went through a few iterations before settling on LibreOffce Calc and Python:

Initially I was using: PHPExcel (https://phpexcel.codeplex.com/) which loaded a given spreadsheet on demand - this was before I though of changing it into a client server model. In a web application context, the response time for anything other than relatively small spreadsheets was simply unacceptable.

I then moved to using Apache POI (https://poi.apache.org/) and used the client server model. This worked quite well but I ran into some problems as some functions had not been implemented yet.

My current thinking is that LibreOffice will continue to improve both in terms of function feature completeness with Microsoft Excel. It may also improve in terms of performance and memory usage.

Any solution that re-implements excel/calc functions, other than LO, most probably has a smaller user/developer base. In my mind, the smaller the projects user/developer base, the more likely active development could slow to a crawl or stop entirely. Not such a great solution for years down the line.

That's exactly the use case the tool arose from.

The main con is the RAM overhead introduced by running LibreOffice instead of splitting the application up into a database and code. For me con this is nullified by the amount of time saved not having to re implement the logic and now, like you mention, the onus is on the team who created the spreadsheet to fix any bugs in their logic.