Page 1 of 2 12 LastLast
Results 1 to 10 of 11

Thread: Kasina SpectraStrobe Info and Resources Repository

  1. Default Kasina SpectraStrobe Info and Resources Repository

    Hi all,

    I recently purchased a Kasina and have been heavily engaged in learning how to create AudioStrobe and SpectraStrobe content (with an emphasis on SpectraStrobe). I've got an extensive background in software and hardware engineering, multimedia, and performance. During my journey to learn the specifics of how SpectraStrobe works I noticed that a lot of the information and some of the available plug-ins seems to be a little bit dated and I had trouble getting up and running quickly (as well as finding a thorough explanation in one place). I ended up reverse-engineering quite a bit from the Audacity plug-ins, and even ended up having to write my own tone generator software to get things perfectly "clean" (I was getting a lot of frequency bleed/harmonics/cross talk that was leading to noisy LED control signals).

    After a bit of trial and error I think I've pretty much got a decent working understanding of the technical details and the techniques involved. I decided to create an open source repository on github that captures everything relevant I've learned and makes it available to others interested in authoring SpectraStrobe content. Hopefully this will allow others to get up and running more quickly, and avoid the time I had to spend learning and perfecting all of the details. Likely this information is out there elsewhere and I just missed it, but either way, hopefully this contribution will be helpful.

    I've provided two project templates, one for Ableton Live, and one for Renoise (not to be confused with Reason) that others should be able to just open and immediately begin to modify to create their own content. Also included are sampler-ready .wav files with the 4 needed SpectraStrobe tones that I was able to use to create the templates. An explanation of how to use everything can be found in the README of the repository.

    The project README contains everything I think is relevant to know to understand how to create SpectraStrobe content, as well as a ton of links to Wikipedia articles that cover the concepts involved for those who are less familiar with the terminology, but who are interested in educating themselves further.

    If anyone who is officially part of Mind Place is reading this, I've put this information out there in good faith and I assume this is all public-domain already and helpful to the community. However if I have violated anything by publishing this information, or I have some of the information wrong, please feel free to contact me and I will take the appropriate actions to remedy any concerns.

    The repository can be found here.

    Feedback and corrections welcome!

    Cheers.

  2. #2

    Default Re: Kasina SpectraStrobe Info and Resources Repository

    This is a great contribution to the SpectraStrobe database. And thanks for creating an Ableton template! I've never used Renoise, it has some interesting features. I never got into tracker software, it reminds me of how the original Synclavier sequencer worked, I was so happy to eventually have a visual timeline gui in 1990 that became standard in the following years among most daws.

    Is there a technical advantage using samples vs oscillators in SS signal creation aside from file size? Using samples seems easier since the frequencies don’t change.

    Looking ahead I’d like to see experiments in creating visual effects.

  3. Default Re: Kasina SpectraStrobe Info and Resources Repository

    dougdi - Besides the file size it will really depend on the sampler and its capabilities. For clarity's sake, in both cases here I was discussing using samples either way, and not using a live generating oscillator plug-in (like a VST). In both cases the computer is playing back the tones by reading samples from memory from a digital audio file. The case with the sampler and looped samples is simply that the sampler, assuming it supports the loop points embedded in the sample files, needs a much shorter audio file (also assuming the loop points are lopped perfectly and don't introduce clip/pop artifacts) to generate the correct tones for durations of arbitrary length. For example the 1 second looped samples I generated/am using are only about 88 KB per tone. If I was to used an audio track with the generated tones for the duration of say 10 minutes, it would be many MB of memory per tone file/track. Plus what happens if you decide to lengthen your session? You will have to regenerate a longer tone track, etc. So mostly it just saves time in workflow and memory/disk space.

    However sometimes samplers have built-in features that normal audio playback in DAW audio tracks do not. For example in Renoise, the built-in sampler has tons of modulation and envelope effects for panning/volume/pitch, etc. which include LFOs that are fully programmable/automatable and oscillate up to 20 hz. If you were trying to achieve that by simply automating the DAW's track volume/panning by hand, first that's going to be a lot of manual editing by hand to generate the waveforms, and secondly that's going to require a bunch of resolution to create track automation envelopes at such high rates (like 20 hz). Now of course you could apply some kind of LFO plug-in or routing in your DAW assuming you have access to it - and apply those to the panning and volume of the tone tracks. But for example I was kind of shocked to find out that Ableton Live, without Max for Live, only has an AutoPan LFO effect built-in. If you want other general purpose LFO plug-ins you need to have Max for Live, and potentially pay even more for a variety of modulation plug-ins, although there may be some good free ones out there. And that's not saying anything about the max LFO frequency they might offer.

    Ultimately though given some of the frequencies reaching towards Gamma waves (approaching 40 hz+) even Renoise's built-in sampler LFOs only hit 20 hz. I don't think most music production makes use of general purpose LFOs at such high rates because most are not worried about the use case of flashing LEDs using audio signals

    I've actually started working on a custom VST plug-in that generates the SpectraStrobe/AudioStrobe tones using wavetable synthesis vs. reading audio files from disk, and so far it's working out pretty well. During testing I've been able to achieve accurate enough generation of the needed tones that it doesn't require bandpass filters or EQing because the signals produced are clean enough that there is no frequency bleed or noise, tested up to 96 khz sample rate. I've also put the needed panning pattern of the SpectraStrobe reference tone directly into the VST plug-in, and applied internal smoothing with a filter to keep unwanted frequency bleed/harmonics during the oscillation of the panning and its working great. Next I'm moving on to creating a basic LFO/modulation VST plug-in that you could put inline with the SpectraStrobe VST and I will make sure that I offer LFO frequencies well into the Gamma range since I'm having trouble finding free/easy LFOs for panning/volume modulation that exceed 20 hz (although they're probably out there). I might create a VST for tone generation as well for binaural/monaural/isochronic, but I'm going to guess there are probably plenty out there already. It seemed like primarily the harder things to find where VSTs to generate and control SpectraStrobe signals (Lux Spectra VST seems hard to find at this point) and LFOs with higher frequency options for controlling panning/volume of a track, so that's what I'm focusing on. I'll add the VST plug-ins to my SpectraStrobe repository's resources section once I'm feeling good about their stability and usefulness.

  4. #4
    Join Date
    Apr 2006
    Location
    Calgary, Alberta, Canada
    Posts
    3,728
    Blog Entries
    3

    Default Re: Kasina SpectraStrobe Info and Resources Repository

    Great work on this information. Little humbled that we didn't write this up ourselves!

    One minor note, if you don't mind...
    Your file format comparison table:

    File Formats

    Precision File Format Pro Con
    Lossless .wav accurate playback large file size
    Lossy .mp3 inaccurate playback smaller file size
    Lossless .flac accurate playback & medium file size not presently supported
    I think you wanted the Pro/Con reversed on the .mp3 line? However, you suggest that .mp3 is "inaccurate", if you mean that it subjectively sounds different, well, that's not actually true, if the files are encoded properly. It's long been determined through many, many double-blind tests that people cannot tell the difference between a .wav and a 320k mp3. A simple google search of "mp3 vs wav" will bring up lots of articles and videos regarding the debunking of the mp3 vs wav audible differences. Certainly, low bitrate .mp3's (like 128k) that came out when the format was new gave the format a bad name, as they were clearly "lossy" and most people could hear the difference. This is where the "bad name" for mp3 came from. People did not understand that you can choose the quality vs. size and there are tradeoffs if you go for smaller file sizes. Properly-encoded high bitrate .mp3's today are indistinguishable from uncompressed wav files. Because of this, there's really no need for Flac format support. Of course, if someone is unconvinced, and really feels that they don't want to use mp3, then there is of course .wav file support, as file size is not really an issue anymore, now that there are 128gig and large micro-SD cards available.
    -Andy.

    Hey, if someone makes a good post, don't forget to click at the bottom of their post to add to their reputation!

  5. Default Re: Kasina SpectraStrobe Info and Resources Repository

    Hah, great catch! Yes those were indeed backwards. I also updated the wording to be a little more useful.

    I appreciate the feedback too! I'm with you on 320 kbps mp3 vs. wav, but I'm not sure everyone understands what you say, although maybe it would be useful to expand an explanation of this in the resources repository. Although the audible difference of 320 kbps mp3 vs. wav is negligible from a listening perspective, we're more concerned with accurately reproduced high frequencies because with SpectraStrobe we're not just concerned with the audible accuracy, but more so the accurate reproduction of very high frequency control signals for the LEDs potentially controlling subtle and high rates of flicker. 320 kbps seems to do just fine with this, but obviously as the bit rate starts to drop below 320 the chance for inaccuracies mount to the extent of a track not even working correctly. I think the fact that mp3 has the cbr/vbr issue as part of its design can lead to some confusion when people are trying to create SS tracks; I've already seen that on the forum. Something like flac is compressed, but is lossless, there's no chance or fussing with accidentally exporting at a variable bit rate, or an insufficient constant bit rate. That said, I agree with you it's not really necessary, hence it having a "wishlist" marker next to it in the scope of the discussion. And where as storage space on the Kasina with microSD cards isn't an issue as you suggest, larger files still waste transfer time and gobble up extra bandwidth if you are distributing your files online.

    It's definitely coming more from my perspective and background as an audio/software engineer: I like my control signals clean and accurate, the thought of not knowing what compression is doing to those control signals is a bit unnerving, even at 320 kbps. Of course in practice this is likely negligible, so it is probably just my idealistic design theory at play here. AudioStrobe/SpectraStrobe are indeed clever formats and pushing the control signals into the high frequency bands solves a lot of issues and makes the technology more approachable to many people, which is a huge win. On the other hand, as an engineer and artist, I feel like having to worry about competing frequencies (audible vs control signals) and potential inaccuracies introduced via compression, even if small, are certainly less than ideal. Typically control signals like MIDI, DMX, OSC, etc. stay "in their own lane" and do not mix with audio signals which keeps the integrity of all signals perfectly intact, if that makes sense. So I'm going to prefer a lossless format when I can, and if I can get some size reduction on top of that, why not (assuming proper encoding/decoding resources are available)?

    Warning, Slightly Off Topic :
    And now we're really getting into the philosophical/theoretical but: if we're going to stick with mp3 format, why not look at embedding control signals into the mp3's id3 header using the "General Encapsulated Object" part of the specification? This lets you stick arbitrary binary data into an .mp3 file with a standard way to encode/decode it. Popular DJ software does this by encoding things like cue and loop points into the mp3 file itself so that DJ software can recall that extra/use-specific metadata at runtime. When the underlying hardware can produce the necessary output signals itself (which as far as I understand is how the Basic Session Editor works), the control signals to drive it end up usually being quite small compared to something like audio data. Usually only a handful of bytes per control change message, and as long as they have accurate timestamps, lining them up with the audio shouldn't be too difficult. They also tend to have much less latency. Demodulating audio signals is always going to introduce some amount of latency (be it Fast Fourier Transforms, Goertzel filter, Bandpass filter, etc.), and when I'm trying to line up my visual pulses with audio pulses, unless visual demodulation latency is known and the audio is being delayed by that known latency as well during playback, there is always going to be a skew between the audible signal and the visual signal, which is also less than ideal. Using a binary encoding of control signals also means it's irrelevant at what bit rate the mp3 file is encoded, but it means specific encoding/decoding software would need to be developed and used.

    Personally I think the next evolution of this technology isn't just audio/visual - it's audio/visual/tactile by introducing low frequency transducers into the mix, and I've already played around with this to great success using the Subpac + Kasina. Ideally, looking forward, I'd love an extensible format that can allow for multiple and separate "channels" so the audio, visual, and even tactile/haptic elements can be isolated and their integrity preserved, with the ability to add future "channels" into the mix, somewhat future-proofing the format for growth with a scalable approach to the types and number of control signals involved. There is only so far you can take adding more and more high frequency control signals in a format like SpectraStrobe/AudioStrobe and you will always be fighting an increasing battle with demodulation latency and frequency bleed. And yes, I'm speaking form pure fantasy now.

    Of course as with anything, it's all trade offs. I'm a particular type of user who has a reasonably high degree of tech savvy and domain expertise with signal processing, and I prefer accurate signal control over "good enough" signal control when I can get it. But admittedly I'm probably not representative of the average user of this technology. I trust that Mind Place has weighed a lot of different approaches and chose to create technology that best balances all of the considerations of both the tech and the users. There are probably a lot of issues I'm not even able to think of without being down in the trenches that would likely reduce the value of some of the ideas I have offered. Ideal is one thing, practical, learned, and applied is another (and almost always the most important). But my mind definitely likes to consider the ideal and muse about it, even if it's not practical at the end of the day.

    I really appreciate you taking the time to read through the resources repository and for sharing the mistakes/typos/and thoughts on the content. I might remove the bit about flac, I kind of wavered on if I should keep it in or not, seeing as how it's mostly a technical preference on my end, but has little relevance on the actual SpectraStrobe specification as you've pointed out.

    Cheers.

    Update: I removed the bit about flac just to remove unnecessary info/confusion from the repository and added a tiny bit more about 320 Kbps indicating that any compression artifacts introduced will be negligible both from a listening and LED control perspective.
    Last edited by Cymatic; 05-06-2019 at 10:28 PM.

  6. #6
    Join Date
    Apr 2006
    Location
    Calgary, Alberta, Canada
    Posts
    3,728
    Blog Entries
    3

    Default Re: Kasina SpectraStrobe Info and Resources Repository

    Thank you!

    I appreciate what you're saying about the quality of the SS signals needing to keep their integrity. Luckily, most people that are looking to create their own SS tracks are fairly audio-savvy. It's generally people that download files from places like SoundCloud or other sites and don't pay attention to the bitrate that get into trouble.

    Interesting idea about the mp3 headers. Unfortunately, though, that would only work for sessions that were being played directly from the SD card. Currently the system has the flexibility of streaming SS (and AS) signals via USB and Audio inputs on the Kasina, and to keep that flexibility would mean that you'd have to have 2 decoding systems - not ideal.

    -Andy.

    Hey, if someone makes a good post, don't forget to click at the bottom of their post to add to their reputation!

  7. Default Re: Kasina SpectraStrobe Info and Resources Repository

    Yes, you're definitely right about that. As I said, it's all trade-offs up and down. I'm just wired as the type of engineer who is always pioneering and thinking about what's next or what the ideal format/spec of a technology might look like. I'm split: I feel like this kind of technology could benefit from an extensible, purpose-built format that includes support for audio tracks, clean channels for multiple control signals, but isn't built *into* the audio track (maybe KBE all beefed up), but then simultaneously acknowledging all of the specificity, trade-offs, and heavy lifting involved in a more custom format/spec and admiring the relative simplicity, flexibility, and ubiquity of something like SS/AS. Having our cake and eating it too is always the most work, isn't it (having multiple decoders, etc.)? Sounds like the Kasina already has 3 decoders (AudioStrobe, SpectraStrobe, and KBE)!

    Backwards compatibility aside for just a moment, I feel like AVS devices are such a specific thing already though that having a specific format, encoders/decoders/playback mechanisms which are purpose-built for them to create the ideal spec (which for me is a multichannel format of control signals and audio) seems reasonably rational/appropriate. I know I'm speaking personally here and not for the vast majority (I'm completely in a bubble here), but: I'm not looking for an AVS device to necessarily be an enhanced mp3 player (speaking specifically to SS/AS, I know it is many things!), personally, I'd rather deal with a specific format built just for this tech. I honestly think the Kasina more or less has this with the KBE session stuff and the SS/AS stuff, but right now they're separate, where as I feel like ideally they would be merged somehow. I don't know much about Mind Workstation for example, but from what I can tell therapists might create content that includes audio tracks of speech, etc. within the sessions they create. Things seem a bit fragmented between session editing and audio capabilities (beyond generated tones) right now. In terms of previewing/streaming such a hypothetical custom format live to a purpose-built device, that's clearly a solvable problem, it's just engineering overhead (albeit not an insignificant amount). Coming to this tech as a late-comer I'm afforded the unique perspective of not having a heavy investment in the prior legacy of the tech, which obviously many do, and for good reason. I'm just looking at it from: what would I want to do with it now, and how would it work? And again, admittedly, I am very naive as I'm just really digging in.

    These ideas/conversations are likely not relevant to the Kasina itself, probably more so of what the future could hold and what devices/tech might eventually become the descendants of the awesome legacy of this technology. In all likelihood I should move the sentiment of my last few replies to a different thread exploring future possibilities of the tech, if anything, but thank you for entertaining me up to this point. Hopefully it's obvious I'm actually quite excited by the tech and have been thinking about it a bit

  8. #8
    Join Date
    Apr 2006
    Location
    Calgary, Alberta, Canada
    Posts
    3,728
    Blog Entries
    3

    Default Re: Kasina SpectraStrobe Info and Resources Repository

    I love your enthusiasm and ideas. Great stuff and keep it coming!

    I think the best win-win solution will be when we can implement KBS & Audio playback simultaneously. Akin to the movie .mp4 + .srt subtitle file, or the karaoke .mp3 (music) + .cdg (lyrics) files, the KBS information would control the lights and the audio track would be just that, an audio track, but the 2 would be "played" together. You could then create Sound & Light tracks fairly easily because they wouldn't need any encoding.

    This idea (likely along with an expanded KBS format) is on the drawing board for the future.
    -Andy.

    Hey, if someone makes a good post, don't forget to click at the bottom of their post to add to their reputation!

  9. Default Re: Kasina SpectraStrobe Info and Resources Repository

    Definitely Andy! I think what you're scratching at there with the ability to combine the tech like that is spot on. If it's possible, and worth the effort over time, expanding the KBS format to include audio and to be versed in maybe a few other few input/output control signals could be a huge win. I'm excited to see where it's all headed.

  10. Default Re: Kasina SpectraStrobe Info and Resources Repository

    Very good and comprehensive writeup! Been looking for reference like this since I got my kasina.

    Quote Originally Posted by Cymatic View Post
    I ended up reverse-engineering quite a bit from the Audacity plug-ins, and even ended up having to write my own tone generator software to get things perfectly "clean"
    Other than Scott's Audacity Plugins you could also include his other work in the resources section too:

    - Gnaural Presets
    - AVS Color wheel (very helpful when programming values)
    - MobMuPlat (iOS/Android apps) - Explanation on Mindplace's blog.

    The last one is particularly interesting because MobMuPlat is basically PureData with a GUI for mobile devices.
    I've been meaning to use Faust or Pd to integrate Audio/Spectra Strobe programically in DAWs which support them (like Radium or Max) but haven't got around to doing so yet.
    FAUST would be perfect since it compiles down to any plugin format you can imagine to target any DAW.

    Every plugin I've come across is 32 bit Windows (Yours are 64 bit ) distributed as a DLL binary only and use the deprecated VST2 standard rather than VST3 or even LV2 :c

    With this and the recent issues surrounding TransparentCorp's products lately, I worry for future software compatibility of Audio/Spectra Strobe, which brings me to...

    Quote Originally Posted by Andy View Post
    This idea (likely along with an expanded KBS format) is on the drawing board for the future.
    Any hopes of open-sourcing the Kasina Basic Session Editor? The main dev; Scott Wilson (Neuroasis) already has a blank repository on GitHub but from what I can tell by past forum posts he vanished or was at least inactive on here for years.

    If the code was lost or as a result the tool is no longer maintained, maybe the KBS format specification could be published so the community could work on an alternative tool?

    At least the editor works in wine on linux (provided you have the unusual dependencies like gdiplus and WMP codecs) so booting Windows just to use it is not required, (From the micro SD card as "upload to Kasina" feature fails on wine like you might expect.)

    I know I can just use Gnaural or a DAW/Audacity to quickly produce a KBS-like session, but that's your standard or compressed PCM audio which takes so much more space than a KBS binary on the micro SD card (especially on hour long sessions) and lose the unique feature of being able to mix in KBS input with AUX from e.g your Phone, one I really like due to the build-in cross-modulation settings.

    If we ever had a plain text format to kbs converter (basically SBaGeN for the Kasina) that would be amazing and repositories with easy sharable presets would be possible. You could share hundreds of presets in just a few MBs.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. SpectraStrobe Sessions for Kasina on SoundCloud
    By Andy in forum Kasina Sessions
    Replies: 12
    Last Post: 06-28-2018, 11:23 PM
  2. Kasina Ganzframe Wiring Info
    By Andy in forum Kasina
    Replies: 0
    Last Post: 04-12-2017, 05:51 PM
  3. Spectrastrobe, Kasina & Mind Workstation
    By mosspa in forum Kasina
    Replies: 21
    Last Post: 10-02-2014, 09:59 PM
  4. Replies: 8
    Last Post: 07-12-2014, 12:15 PM
  5. Replies: 5
    Last Post: 03-17-2014, 08:04 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •