MartinusMagneson's picture

Magneson (@MartinusMagneson)

Compositions

MartinusMagneson's picture
Magneson posted a new Node Set, “Magneson's List Tools [Deprecated]
MartinusMagneson's picture
Magneson posted a new Discussion, “Nested for loops
MartinusMagneson's picture

The sample color from image node needs a hold node in front of it (between resize image), also both hold nodes will need to be triggered from the "process item" port, not the showed window.

MartinusMagneson's picture

From an audio engineering perspective, I can't really say I like the idea of ms as a measure for samples. How about the default node using samples, and then display the ms in the output info?

Samples for buffer size is pretty much the conventional way for good reasons. The latency you'll get from 512 samples is also variable dependent on the sample rate of the audio interface. If you increase the sample rate of your audio interface to 96kHz you'll be able to cut the latency in about half as well. Provided you use the conventional buffer sizes (^2), the step from 128 to 256 at 44.1kHz would result in 2.9xxx ms and 5.8xxx ms respectively. The next step up (512) is at 11.6xxx ms. This results in having to round up or down, and you as a user/programmer wouldn't realistically know where you were regarding the buffer size if you set it somewhere in between. In reality you wouldn't get anything but a rounding to one of the sample sizes. That way I'd think it would be simpler to easily select the desired sample rate and the see the resulting latency.

Furthermore, when getting to the nitty gritty audio programming if/when that time comes, having a ms base/convention when dealing with audio programming isn't that easy or accurate. FFT and the likes where you need to know where you are on a sample basis would then become near impossible as you're dealing with a bunch of samples at 1ms - even at 22100. Then real -> int and indexing also becomes an issue.

When that is said, 512 samples is a huge buffer in itself, not to mention 4096 - at least when dealing with fewer than 16 channels with little processing.

MartinusMagneson's picture
Magneson posted a new Discussion, “How random is random noise?

How random is random noise?

I have noticed for quite som time that the perlin noise isn't really that random. It seems to be the same everytime the composition is restarted. Furthermore it seems very much like it's centered around 0, instead of being all over the place (which is desireable for me at least). A last issue with it is that two Noise nodes will produce the same result in a composition. Is all of this by design? In that I'll have to use the timebase (add to time) to get different results? These are the Vuo products of a composition running two times:

Pages