Transcode() as a Bottleneck

[Ignotus-mago]

(copied from PixelScanner Issues)

Should the transcode(int) and transcode(float) methods be called everywhere that transcoding happens in other methods in PixelAudioMapper?

        public int transcode(float val) {
         float vout = map(val, -1.0f, 1.0f, 0, 255);
         return Math.round(vout);
     }

    public float transcode(int val) {
         float vout = map(val, 0, 255, -1.0f, 1.0f);
         return vout;
     }

We do this mapping almost everywhere. If we want to use different ranges for the img[] and sig[] arrays, using transcode as a bottleneck would mean we only have to override these two methods to change behavior in all methods that map audio to RGB or RGB to audio. The overhead of a method call should be minimal. SO, I guess the question is in what circumstances would overriding be useful?

Perhaps we want to make the library only work for RGB [0, 255] and audio (-1.0..1.0)? Could it easily handle 16 bit channels, for example, or a much wider signal amplitude range, with just a change to transcode?

Well, no. Bitshifting is also used throughout the RGB math, but that could be overridden too, I think. Changing the audio range would be simpler. For example, we could handle 5 volt peak-to-peak signals without normalizing them to audio range. Is that useful?

[Ignotus-mago]

I recommend creating a branch with transcode() (or renamed transcodeInt(), transcodeFloat() methods) used as a bottleneck to see how well it works. Not a high priority, but should be tried before releasing the library. How does it affect speed? How useful is it really?