I'm building an app with AudioKit where I went to be able to re-order the processing chain occasionally. E.g., I might have "wav" -> "reverb" -> "filter" and I want to swap things around so I have "wav" -> "filter" -> "reverb".
What I'd like to do is call AudioKit.stop(), replumb the inputs to existing nodes, then call AudioKit.start() again. However, it doesn't look to me like you can change the input to a node beyond the constructor, so I then need to copy the state of each node, create a new one with the same state, and then setup my chain again.
Is there a simpler way to achieve this without having to destroy and remake nodes with the same params each time?
For your example I'd consider just going with wav->reverb->filter->reverb and then bypassing the reverb you don't want to use. A bypassed effect should not bear any burden on your CPU, so it should be fine. That solves your example, but for a more general solution, yeah, you have to rebuild the entire chain. Members of the core team are working on this very issue, but for now, I think this answer will have to suffice.
Related
It appears that xsl:message does not work (i.e. no output is generated to message list) within an accumulator-rule. However, I don't see anything in the spec that disallows this.
<xsl:accumulator name="acc1" streamable="yes" initial-value="1">
<xsl:accumulator-rule match="cdf:ContestSelection">
<xsl:message>Output</xsl:message>
</xsl:accumulator-rule>
<xsl:accumulator>
There's all sort of possible reasons for this: the accumulator is never used, the rule never fires, the optimizer optimizes the call on xsl:message away, etc. One would need a complete repro to see what is actually going on.
Note that pretty well everything about xsl:message is implementation-defined, and one reason for that is to give the processor maximum freedom for optimization.
In an attempt to smooth out crackling/zippering when changing parameters on an AKDelay, I switched to using AKOperationEffect. However, unlike AKDelay, AKOperationEffect has no dry/wet mix parameter. How do I change it?
I wound up composing a wrapper class with an optional AKDryWetMixer node that I just use for cases where the effect needs an additional dry/wet mixer (as is the case with AKOperationEffect). Seems fine.
Obviously, if there's a "proper" solution, or something obvious I'm missing, I'd appreciate a heads-up.
Instead of creating new WebGlProgram's using gl.createProgram() is it a good idea to keep reusing one?
I am listing the steps that I should be doing if I am to reuse one:
AttachShader(s): in my case I need to attach a new Fragment shader only. (Question: Can I hang on to a compiled shader?)
linkProgram
useProgram
getAttribLocation
getUniformLocation
What are you trying to do? 99.9% of all GPU apps make shader programs and are done. They might make 1, they might make 5000, but they aren't ever in a position where they would even need to consider your question. So what are you really trying to do?
Those few apps that do allow you to edit shaders (shadertoy, glslsandbox, vertexshaderart, ...) either make new ones and delete old or reuse. There's no benefit to one or the other it's just a matter of style.
Yes you can hold on to shaders. You can use shaders with multiple programs. It's common to do so.
If you change a shader it won't affect a program unless/until you relink that program with gl.linkProgram. Anytime you call gl.linkProgram and it's successful all your previous uniform locations for that program are obsolete and you have to query new ones.
In my extension, I need to write a huge file (say around 20 gigs) to the disk. Currently I am doing it in the main thread, but file creation is very expensive operation. I was about to move the whole file creation process to a ChromeWorker, but based on https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Functions_and_classes_available_to_workers I cannot have access to the nsiFile from a ChromeWorker.
So my questions are:
1. Is it possible to access Cc, Ci, and Cu from within a ChromeWorker?
2. If not what would be the most efficient way to create and fill large files in Firefox. Note that I need to write the file based on segments and offsets (Ci.nsISeekableStream).
It's not possible to access nsIFile from ChromeWorker. But nsIFile is horrible synchronus option.
Go with OS.File: https://developer.mozilla.org/en-US/docs/Mozilla/JavaScript_code_modules/OSFile.jsm
On that page go to the link for usage on workers: https://developer.mozilla.org/docs/Mozilla/JavaScript_code_modules/OSFile.jsm/OS.File_for_workers
On the mainthread os.file returns promises.
In worker they are synchronus. Wrap your os.file functions in worker with a try-catch, as when an error occurs, (like os.file.remove with option of ignoreAbsent set to false) then the catch will hold the OS.File.Error object.
Great move to ChromeWorker btw! I'm a huge fan of ChromeWorkers. I wrote a simple example of jsm using chromeworker here: https://github.com/Noitidart/jpm-chromeworker
For segments, you'll have to OS.File.open and then on the return value do a .setPosition() then you can read certain number of bytes from that position, or write, or whatever. Its awesome stuff. OS.File is the new way and the recommended way to do file operations. Its been around awhile now though since like Firefox 29 or before that.
I'm writing tests with EUnit and some of the Units Under Test need to read a data file via file:consult/1. My tests make assumptions about the data that will be available in /priv, but the data will be different in production. What's the best way to accomplish this?
I'm a total newbie in Erlang and I have thought of a few solutions that feel a bit ugly to me. For example,
Put both files in /priv and use a macro (e.g., "-ifdef(EUNIT)") to determine which one to pass to file:consult/1. This seems too fragile/error-prone to me.
Get Rebar to copy the right file to /priv.
Also please feel free to point out if I'm trying to do something that is fundamentally wrong. That may well be the case.
Is there a better way to do this?
I think both of your solutions would work. It is rather question of maintaining such tests, and both of those rely on some external setup (file existing, and having wright data).
For me easiest way to keep contents of such file local to given test is mocking, and making file:consult/1 return value you want.
7> meck:new(file, [unstick, passthrough]).
ok
8> meck:expect(file, consult, fun( _File ) -> {some, data} end).
ok
9> file:consult(any_file_at_all).
{some,data}
It will work, but there are two more things you could do.
First of all, you should not be testing file:consult/1 at all. It is part of standard library, and can assume it works all wright. Rather than doing that you should test functions that use data you read from this file; and of course pass to them some "in-test-created" data. It will give you some nice separation between data source, and parsing (acting on) it. And later it might be simpler to replace file:consult with call to external service, or something like that.
Other thing is that problem with testing something should be sign of bad smell for you. You might think a little about redesigning your system. I'm not saying that you have to, but such problems are good indicator to justify on . If you testing some functionality x, and you would like it to behave one way in production and other in tests (read one file or another), than maybe this behaviour should be injected to it. Or in other words, maybe file your function should read should be a parameter in this function. If you would like to still have some "default file to read" functionality in your production code, you could use something like this
function_with_file_consult(A, B, C) ->
function_with_file_consult(A, B, C, "default_file.dat").
function_with_file_consult(A, B, C, File) ->
[ ... actual function logic ... ]
It will allow you to use shorter version in production, and longer just for your tests.