Firefox seems to have a buggy implementation of this audio node (see this question) so, as I suspect bugs in deprecated features are unlikely to get fixed, I'm looking for another solution.
Mozilla's website says createScriptProcessor is slated to be replaced by audio workers "soon" but work on that doesn't even seem to have begun yet.
All the libs I've looked at seem to use createScriptProcessor. You can get at time domain data from within Analyzer Nodes so that's my next lead but that also seems pretty kludged so I thought I'd ask here in case I've overlooked a better way. Thanks!
Related
I have an AudioWorkletNode that only takes an input to perform visualization of audio. It outputs nothing, and yet, nothing is happening unless I connect it to BaseAudioContext.destination. This seems silly if it's intentionally designed this way.
I'm assuming you are using Chrome since this is the only browser which supports the AudioWorkletNode so far. In that case it is a known issue. Unless something is connected to the destination Chrome will not process it. The ScriptProcessorNode does for example suffer from the same problem.
I tried to find a tracking bug on bugs.chromium.org but couldn't find one. Therefore I created one: https://bugs.chromium.org/p/chromium/issues/detail?id=1045926
A library that I maintain called standardized-audio-context has a fix for that, although it might be overkill if this is the only workaround you need.
I'm getting into using IndexedDB. Thought I'd grab Parashuram's jQuery wrapper for it.
However, there doesn't seem to be a whole lot of information regarding IndexedDB lying around the internet.
Does anyone know what the I/O speeds are like on IndexedDB, preferably browser-specific? Is there any way to measure it? How would using the jQuery wrapper (as well as the polyfill shim to make it work in Opera/Safari) affect these speeds?
Reason I'm asking is I thought to store snippets of HTML content in the base, but maybe I shouldn't bother if fetching it would take longer than browser cache or similar.
It depends on the browser your are using.
My experience is that IE 10 is pretty fast, compared to chrome and FireFox. Try my QUnit test I wrote for my framework, and you will really see the difference. Of course this isn't a benchmark test, only test of functionality.
I've recently gotten hold of a Rexster server with a REST API and I've been wanting to play around with it in an interactive way. I've never had to work with REST before, most of my work has been around SOAP and .NET. I'm able to trivially perform all of the GET operations just by navigating to the correct URL through the browser and reading the response with JSONView on Firefox, but anything requiring PUT and DELETE appears to require actual code.
Given that I'm still prototyping and testing the API, I'd like to have a way to interactively throw a bunch of requests at it and see what happens. I'm sure I could concoct something in Java or C# fairly fast, but I'm guessing there's a better way (which is why I was thinking javascript above) and was hoping you folks might recommend one.
Please advise, thanks!
If you are trying to debug requests and responses, then Fiddler or HttpScoop is great. However, for just interacting with the API, I've found that the Poster plugin for Firefox is the easiest of all. That sounds like what you're describing.
If you are on Windows, then Fiddler is your best option. I believe the Mac has an equivalent called Charles.
Recent versions of SoapUI allow you to interact with REST interfaces.
Maybe it won't affect you, but there's a bug in the current open source version that causes every query to be executed twice - took me some time to discover while testing a service that returns an incrementing number :-)
I am working on a project to convert a web site that is fully functional in Internet Explorer 8 and lower, but does not work well in Firefox or Safari.
A lot of what will need to be changed is going to be javascript-related (aka methods that exist in IE but not in other browsers).
What I want to know is whether anyone is aware of a fairly comprehensive list of common things that have to be changed to work accross all browsers.
I am starting with quirksmode.org but I don't think it will have quite everything I'm looking for. If anyone knows of a list please let me know.
Your best option here is to go with a Javascript toolkit/library like jQuery, MooTools or Prototype. Such a decision will save you a monstrous amount of work, and all three are constantly being updated which gives you a large degree of safety against future compatibility issues. Especially for DOM manipulation or AJAX, a library is the way to go.
If you absolutely mustn't use one, quirksmode is a good start. I've never found any single source that is comprehensive enough to keep me from running back to Google for each problem area.
Quite honestly, if you don't have lots of experience doing cross-browser development, I suspect the best way to fix your app is to set up a good test environment on each target browser and starting finding where it breaks. You're eventually going to have to test it on each target browser anyway, so you might as well start there. Once you find out what code is failing you for a particular bug, you can do more targeted searches for how to work around that issue in a cross browser way.
You will, over time, build up a good internal knowledge base of what is safe to use in a cross browser way and what is not. Even experienced developers still run into new issues on every project that are only found with testing. One advantage of experience though is that you start to learn when to suspect that something might or might not have cross browser issues and either avoid it (find a safer way) or explicitly test it in several browsers before you use it.
I find that http://jsfiddle.net is awesome for creating very efficient self-contained test cases to either proactively try something in other browsers or to troubleshoot something that's been giving you a problem.
As others have said, one huge advantage of the various browser libraries like jQuery or others is that they have solved a lot of these compatibility issues for you and, in general, if they document a function in the library and don't explicitly warn you about cross-browser issues, then they've already done their homework to make it safe for you.
You may also find out that using a javascript framework such as jQuery, ExtJs, Prototype, Mootols, ... would be very beneficial in writing cross browser javascript.
a web site that is fully functional in Internet Explorer 8 and lower,
but does not work well in Firefox or Safari
I would strongly recommend to develop with a browser that meets the standards (e.g. CSS3).
The process should rather be: to develop with FireFox or Chrome - and fix all IE versions later on.
Well, this is my daily bread... and ordinary it's IE b*tch which makes me loose time...
Let me start by saying I really appreciate the work done at QuirksMode.org but in recent experience the content seems a bit dated.
Some pages haven't been updated from anywhere between 6months and a year.
Compatibility tables still only show chrome at version 5.0 (W3C DOM Compatibility) or 1.0 (Event compatibility tables)
In cases where content seems a bit dated I generally refer to Sitepoint's References, but their HTML and Javascript Reference pages are also a bit our of date.
What compatibility reference guides do you all use?
update
I'm aware of sites like CanIUse, which are invaluable reference new feature support like new JS API libraries and CSS3 support. However I'm more interested in things like supported attributes (bad example I admit) and browser events. The more vanilla stuff.
And please, noone mention w3schools (see w3fools why you should never use this site)
http://caniuse.com is quite good and (provided you use the correct keywords) has good search functionality as well.
In addition to the above you might be interested in the ES5 compatibility tables that Kangax maintains at http://kangax.github.com/es5-compat-table/
update
In the meantime there is also the ES6 compat table. Quite red for now (9/2014) admittedly, but getting more and more useful.
I trust Quirksmode, have you any idea how many tests PPK runs? It's not that it's outdated (yet!) it's that CSS support (and Browser uptake) has reached a new level, trust me you will appreciate the experience if you have to support an older browser.
Not every FF or Opera user updates quickly anymore which is what could be relied on for a while! - so yes you're right to question the findings. personally I look for recent sites too but I don't "trust" them nearly as much as the older and even then I tend to test for myself.
There's no replacement for experience IMO often these guys can "guess" at what may be the problem based on their past experience even if the so called "bug" or unexpected display is new to them in that context.
I have a "bug" report detailed on PPK's site - yea it and me are old - but only last week I got asked about something (seemingly unrelated) which turned out to be the same thing and have the same solution, it's IE7 related so will be with us for a while yet. (I see caniuse thinks that's old eeek!) - I am completely in awe of these guys who have kept up these sites for so long, if you can reverse engineer the bugs you get to understand the browsers.. that will never fail you as long as the browsers are on the go - their render engines don't usually change all that much between versions!
but then again this is a new era of Browser wars so who knows what will happen :)
Have a look at this big javascript compatibility table
http://compatibility.shwups-cms.ch/de/home/
Its very big, but checks at the moment only for existenz of javascript properties.