i'm making a research for the topic of getting a mp3 file rendered as waveform. i've already found some php libraries. now i'm looking for a similar solution in nodejs.
my results so far are:
https://github.com/afreiday/php-waveform-svg
http://www.schillmania.com/projects/soundmanager2/ (maybe loading this in nodejs to try rendering the wave file in svg-format... not quiet sure)
have you guys experience with nodejs-libraries to create waveforms in svg format?
Not a directly nodejs-related solution.
We use a Linux commandline tool Sonic Annotator to extract waveform (peaks) and detect beat in audio files. Its a host that can run VAMP plugins that are quite good at these tasks.
Peaks are extracted as a set of floats from 0 to 1 at equal intervals. SHould be rather simple to build an svg on top of that data (with D3 i.e.).
I'm not used to nodejs, but the docs says it can run external commands.
Related
I'm writing a JavaScript library which outputs SVG diagrams. To calculate layout of these diagrams the library requires font metrics to make diagram shapes fit text in them.
I want this library to be usable in both web pages and command line for batch rendering.
In the browser, fonts are available and I can get text metrics via Canvas API. It works fine.
In the command line, there are system fonts and stuff like QFontMetric. I can use Qt Script to run the library. It is also quite easy to integrate PDF and PNG exports. But that would mean to write wrapper in Qt.
The question: Does Node.js have a support to access system fonts and get their metric? Or is there a better way to implement such CLI tool based on JS library?
Node.js does not have built-in functionality for this, but there are certainly npm packages out there to get those metrics.
A quick googling brought up a package called fontmetrics, which seems to do exactly what you asked for.
I am willing to programmatically generate file previews for a large set of Adobe files. This should be done programmatically (not via user interface via recorded actions).
The idea is to generate jpg/png previews for psd files, pdf preview for indd files and so on.
Is there a library or SDK to easily do that?
I am open to every programming language that can get the job done, however I prefer a js solution since I am willing to run the script on a nodeJS server.
Is there any system requirement or program to be installed to make this thing work? Do I need an Adobe subscription to do that?
Thank you in advance.
I cannot find yet a proper solution in JavaScript. But this is a reference link I found on search engines.
https://unix.stackexchange.com/questions/11835/pdf-to-jpg-without-quality-loss-gscan2pdf
With ImageMagick on a server, it may help solve the problem.
Another reference link is on about to improve the speed and reduce the memory consumption. This may also help you integrate it on your server.
https://serverfault.com/questions/167573/fast-pdf-to-jpg-conversion-on-linux-wanted
This code snippet may help you. You may have to apply back-ends on your server instead of directly integrating it in your NodeJS server.
convert -density 300 file.pdf page.jpg
I'm interested in using Cesium to build a 3D Earth with custom tiles, but as per the "get started" instructions here, it seems as though you have to download a massive 30mb directory and include the whole thing in your project to have it run correctly. Is this true? Can I not just include Cesium.js and get running like that? I don't need 80% of the UI elements they include anyways.
At the end of the "get started" tutorial, they seem to indicate that all you need to get running are these bits:
<script src="Cesium/Cesium.js"></script>
#import url(Cesium/Widgets/widgets.css);
<div id="cesiumContainer"></div>
var viewer = new Cesium.CesiumViewer('cesiumContainer');
But when I set these bits up, I get this error: "define is not defined" and "Cesium is not defined".
What is the lightest possible way to run Cesium?
That tutorial definitely needs an update and I'll make a note to clean it up. (For starters, there's a bug at the bottom of it, because Cesium.CesiumViewer should just be Cesium.Viewer.) That being said, here's the low-down on what's included in the zip and what you'll want/need for actual development.
Apps -> Sample applications.
Source -> AMD modules for module-based development (requirejs, browserify, etc..) also used by the sample applications.
Specs -> Unit tests.
ThirdParty -> Third party libraries required for the above.
Build/Apps -> Built and minified versions of the sampled applications.
Build/Documentation -> The reference documentation.
This leaves two directories, Build/Cesium and Build/CesiumUnminified, which I'll talk about in a minute.
But first, the technically correct answer to your question is to create the lightest possible Cesium-based application, use the AMD modules we provide. This means you only need to include the Source folder at development time, and then your build process will create the minified and concatenated version of your app for deployment. Using modules ensure you only include the Cesium features you are using. This is different than the "traditional" web development practice of including minified versions of all of your code and libraries in the correct order via script tags at the bottom of your page. Modules are gaining momentum on a daily basis and ES6 along with build systems like Babel are slowly taking over the web dev landscape. We use requirejs ourselves, but there are tons of options out there.
An example of an application built this way is the Cesium Viewer example in Build\Apps\CesiumViewer (source is in Apps\CesiumViewer). The entire built app (uncompressed) is 8.77 megs and exposes pretty much every Cesium feature and capability. 3.65 megs of that is the Natural Earth imagery that ships by default and other data files that the app only pulles down on demand if you use a feature that triggers it. The remaining JavaScript is greatly reduced in size by gzipping compression on the server end. To see this for yourself, run the latest Cesium Viewer link and open the network tab in your browser dev tools. The entire app only sucks down 2.2 megs (and that includes the initial imagery being loaded from Bing. The Cesium portion is only about 426kb. It might suck down a few extra kb if you start loading GeoJSON or KML files, but not much.
Since a module based approach requires additional set up and is still not that common in web development overall, we also supply the Build/Cesium and Build/CesiumUnminified folders. These included fully minified and concatenated versions of Cesium that suck all of the modules into a single file. However, you need more than just the Cesium.js file for deployment. Here's a break down of these folders:
Build/Assets -> The default imagery/assets that ship with Cesium (imagery/icons/stars/data for ICRF transformations). This data is pulled down as needed depending on how you configure your Cesium application. It's 3.65 megs, but chanes are your app will only ever touch a few kb of that (depending on the features you use). Rather than try and determine what to deploy to the server, I suggest deploying the entire directory (but as I said, the client may never retrieve most of it).
Build/Workers and Build/ThirdParty -> These contained the concatenated web workers used by Cesium. This includes code used by imagery/terrain, geometry tessellation, and zip file handling. It's pulled down on demand and even if you did something to require all of it, is still under a meg gzipped. These files can't be included in the primary Cesium.js because of the nature of WebWorkers (In our opinion this is a difficiency in the spec).
Build/Widgets -> contains the concatenated CSS, both in inidividual widget form and in a combined widgets.css file. I recommend just including widgets.css and be done with it (4kb gzipped); but if you are really concerned about size you can bring down individual css files. This folder also contains icons used by the various widgets. Once again, they are only retrieved from the server if needed.
As their names suggestions, Both Build/Cesium and Build/CesiumUnminified are pretty much the same thing. The main difference is that Build/Cesium has been minified and is much smaller. It is also faster because it has a lot of debug code removed in order to improve performance. Our official recommendation is to develop against CesiumUnminified and deploy using Cesium. This will make it easier to develop because you'll get better error handling and callstacks if there are problems in your code.
An example of an application built this way is the Hello World application link. There's actually not much size difference from the built Cesium Viewer app I linked above, but that's because they are essentially the same application built two different ways.
So this answer ended up being a lot longer than I wanted it to be, but Web Development is varied and Cesium tries to do its best to support all of its different approaches. Cesium itself is also incredibly ambitious so we've had to overcome a lot of hurdles that other projects never encounter. Is there room for improvement, absolutely, but we go out of our way to ensure that Cesium is as light as it can be while delivering the features that it has. I think in a 2.0 version we will probably take this even further and try and make things more modular.
I hope that answers your questions and concerns.
I need to display some data online but I also would like to have nice plots as high-res files for printing. So far I was generating the plots as png, but now I am thinking on changing this to Javascript. This is mainly because I would like my plots to be dynamic.
The WWW part is looks relatively easy for me; I would grab data from a server with AJAX and plot on a webpage - I think SVG would be perfect for my needs. But how can I run the script from terminal with a file name as a parameter to get a myplot.svg (which of course will not be dynamic any longer) file that looks like the plot on the webpage?
Ideally I would like to have a single plotting subroutine in order to avoid duplicate code and to keep both versions looking the same.
So my questions are which framework should I use for SVG generation to make the terminal variant easy ?
You can use ImageMagick to convert a SVG to png:
ImageMagick convert svg to png
You can extract the generated SVG from a virtual DOM (with the same code as on your web page, perhaps with slightly differences regarding environment) when you use Node.js and jsdom
As mentioned in the comment I can recommend D3.js - Data Driven Documents for generating SVG the easy way.
An alternative for Node.js and jsdom might be Phantom.js.
Your task is not an easy one, but it's worth the effort. Good luck!
I made a game using Construct 2, I first try to use PhoneGap build to make the app but I realized at PhoneGap game are extremely slow. So I heard that CocoonJS can solve this problem. I tried to to make a CocoonJS game by exporting within Construct 2 but you are required to purchase the update. I also tried exporting to HTML Game and uploading to CocoonJS and testing on a iPhone where all I got was a black screen. I don't quite understand what format the game need to be in. What kind of struture is needed. If any has been in my situation or know how to solve it please help. I am no a really short deadline.
For CocoonJS:
When exporting from Construct 2 with the CocoonJS option it packages it in a .zip file. So try putting your files in a .zip and try that. If you're getting a black screen after that you may not have packaged the .zip correctly, make sure the index.html isn't buried inside another folder in the .zip file.
For more information, check this out: http://wiki.ludei.com/cocoonjs:launcherapp