Audio channel input for systems with tape support?

[nekoniaow]

I realize that this might be an unconventional suggestion, technically as well as user experience wise but maybe you might think there is some value to it, so bear with me for a few paragraphs. ;)

Upon reading a Symoon post on the "Experimental very fast tape loading" thread on the Defence Force forums where he attached a ZIP file containing WAV files to be used as tape input for physical Oric machines, I wondered about the feasibility and practicality of being able to emulate a similar setup. (The post: http://forum.defence-force.org/viewtopic.php?p=17538#p17391.)

Since I do not have access to an actual Oric at the moment, I must resort to emulation to test Symoon's fast loading technique. However, it does not look like Clock Signal offers a way to use an audio file to emulate a tape input signal at the moment.

Providing an user interface of some kind to allow the (necessarily interactive/dynamic) specification of an audio file to be used to emulate the tape input signal seems simple enough. It even seems possible that some other Oric emulators already offer such an interface and adding one to Clock Signal does not seem particularly technically challenging (feel free to contradict me though, I would love to learn about it).

But, another idea popped into my devious mind:

what if, instead of offering a conventional "please choose your audio file to be used as tape input signal" selection dialog, Clock Signal simply used an actual macOS audio input channel for tape signal input?

I see several advantages to such a system:

• no need to offer a silly selection dialog, users are responsible for sending audio to the emulator
• most macOS applications which output sound allow to configure on which channel to send the audio, so users can use their favorite app and possibly scripts
• users are in perfect control of when they start playing audio, just like they are on an actual Oric (or other) machine
• audio streaming/mixing systems/apps such as "Audio Hijack" and "Loopback" from Rogue Amoeba allow to interject audio processing filters in between the audio source and the receiving channel, offering potential ways to enhance signal decoding by the emulated machine when using digitized audio from actual cassette tapes, possibly damaged. (Audio Hijack: https://rogueamoeba.com/audiohijack/.)
• technically, this is much simpler to implement: just read the bytes from the input audio channel, no audio format to decode, no library to add, etc.
• this is actually real audio input emulation and kinda really fits with Clock Signal "signal" philosophy.

What do you think? ;)

[TomHarte]

I wanted at least to support all the audio formats offered by CoreAudio, and WAV for SDL, but have never quite done it because I couldn't find an obvious way to say in my Info.plist that I just support everything CoreAudio supports. It seemed to require a manual recitation.

I hadn't considered live audio capture but I guess it would end up being essentially the same task. I'll look into it.

The only issues I can think of offhand are that obviously the static analyser wouldn't be able to predict which computer audio is for in advance if it can't actually see the audio in advance, and my UI simplification of just expecting users to drag-and-drop media onto running machines to change what's inserted doesn't really map across. Both feel minor.

[nekoniaow]

Indeed, the static analyzer cannot predict which audio the user is going to elect to send towards Clock Signal and thus cannot automatically trigger a preset sequence of operations.

This feature would need to run in addition to the usual .tap file drag and dropping mechanism but is not suitable as a replacement for it since its end goal (in my view) is to replicate the original behavior of the machine.