MidiFire/StreamByter - some myths debunked

I don’t post here very often (prefer to keep discourse about my apps on my own forum), and I suspect I might cop a bit of flak for this, but I want to address some of the comments I have read here recently regarding my apps and make some more general statements about MidiFire and StreamByter and how they work as a reference.

1. StreamByter is hard/arcane/assembler-like/inefficient

Actually, the StreamByter language is very simple (see below). The complexity of MIDI scripting really comes about from needing to understand how MIDI itself works; I would argue that this holds true for any MIDI scripting language. Without understanding MIDI it all appears esoteric. For anyone who understands MIDI, StreamByter makes a lot of sense - it was designed around the MIDI protocol after all.

When boiled down, the StreamByter language consists of just 5 simple commands, generic pattern matching and array variables:

ASS - assign values to array variables
SND - send a MIDI message
MAT - perform a calculation
IF/ELSE/END - conditionals and loops
SET - configure labels and sliders
[input MIDI message] = [output MIDI message] - rewrite a MIDI message using patterns

array variables are just slots of memory (or special values like random, timing, current message or slider) that are used in the above rules.

and that is it.

The language is relatively strict in terms of syntax - this is to make it easier to parse.

I read a comment where someone suggested that StreamByter was inefficient - this could not be further from the truth - Internally StreamByter is massively efficient and carefully hand-coded in pure C (my specialty) - the textual rules are not evaluated dynamically at run time but converted to a binary format and processed at almost bare-metal speed.

Another comment stated that I had made sliders 'difficult' to work with in code. I disagree. A slider's value can be read inside a script by just looking at a variable value. Adjusting a slider from code is done by setting that value - it's dead simple. Changing the name of a slider and its range is a simple SET statement. You can get more advanced if you want and get notified in your script when a slider is moved by looking for a specific MIDI message.

2. You need to know StreamByter for MidiFire

An enormous amount of stuff can be done in MidiFire without needing to go near any scripting. This includes channel/note remapping, keyboard/velocity splits, velocity/pressure curves, sophisticated/accurate MIDI clock, event monitoring, automated CC sweeps, poly to mono conversion, bluetooth/wifi management and remote control of everything via MIDI learn.

MidiFire’s MIDI routing is second to none - it’s totally freeform (no ‘lanes’ or ‘matrices’) - you just drop port and module blocks onto a canvas and connect them in any way you like and MidiFire will sit up and beg. Route, clone and merge ad nauseum all by making connections between blocks. Internally, MidiFire routes using a recursive descent engine, again carefully coded in native C (as are all modules), in order to move MIDI events through the graph as fast and efficiently as possible.

MidiFire scenes and StreamByter scripts are completely portable between iOS and macOS. The same StreamByter code running in AUM will work in Logic Pro X. Both apps have minuscule memory requirements and low CPU overhead even with large rates of events and complex processing.

Scripting is the icing on the cake - it’s designed to allow me, or users if they wish, to extend the capabilities of MidiFire to cater for the thousands of specialised use cases that exist. How anyone believes that a single app can do this with a GUI escapes me.

3. My app philosophy

Because I understand that not everyone wants to write scripts, I stand behind my apps (which is why they are priced as they are, but that is a whole different story) and am always happy to hear from customers with a specific requirement and be able to supply them with a working solution. Those who have tapped me for code via email or via my forum can testify that I respond fairly quickly. Timely and comprehensive support is something I feel should be included in the price of admission for my works.

StreamByter originally appeared in MidiBridge and was really just for me to remotely extend that app’s feature set on demand. Turns out it grew legs and people started using it and so I continued to develop it. I do understand that scripting is not for everyone and that is fine, but I do get disappointed when people (often who have never even used my apps) dismiss them out of hand when in reality scripting just does not suit them (don't get me started on 1 star reviews), even if they have a special use case that needs to be met, and could be satisfied by just asking.

Finally, and this might be the most controversial (and probably needless) comment, but I want to get it off my chest; I have a massive ego. Every app I release is always a first-of-its kind; from MidiVision and MidiBridge to MidiPace. I try to identify a need that is currently not filled and make a new niche rather than make a ‘better’ version of a pre-existing product. Many of my apps have been copied, ranging from concept/features to one that ‘borrowed’ the entire app, UI and all. That’s the nature of competition, but it is not something I tend to do myself. Specifically, the latest StreamByter release has been in the works for a while with many of the enhancements having been on the to-do list for up to a year.

Regards, Nic

PS. I do realise I am stirring a hornets’ nest. ;-)

«13

Comments

  • Thanks for the explanations.

    All seems pretty fair and I must admit to being a bit tempted to check these apps out now.

  • wimwim
    edited April 12

    I get a kick out of the challenge of solving problems with Streambyter. But give me the choice between a GUI like mfx Strip and coding ... I’m gonna skip the coding and make some music.

    Thanks for adding decimal. Hex conversions impress the ladies, but kill my libido.

    Add AND logic to IF statements and I’ll kiss ya’. B)

  • I appreciate the effort put into these apps and the flexibility in processing they open up.

    But coding is my day job and I’m more likely to want to wang yet another distorted open A chord at silly volumes than stare at script in my leisure time. Actually I’d rather be woodworking. Now I mention it I don’t like coding anywhere these days. Time for a change.

    Hey, you do a GigRig app ... big fan of Dan and That Pedal Show here.

  • They are great apps and I always appreciate the great support as well. Any plans for a Windows version of Streambyter? Love to be able to use it in my desktop projects.
    The decimals and gui additions really help, hopefully more gui elements can be added later on in the future :)

  • @TheVimFuego - yeah, I'm the official GigRig iOS app developer - Dan is a legend!

    @Carnbot - no plans for windows I'm afraid; although much of the code is in C, MIDI and UI is completely different under windows; I last did windows programming in '94 and was hoping to keep it that way ;-)

  • Yep, fair enough :) will need to get a Mac at some point anyway.

    @audeonic said:
    @Carnbot - no plans for windows I'm afraid; although much of the code is in C, MIDI and UI is completely different under windows; I last did windows programming in '94 and was hoping to keep it that way ;-)

  • edited April 12

    I don’t want to hijack this thread, but I think it’s nice to keep the debate open.

    I didn’t want to offend on the other thread. I’m incredibly grateful for the help and coding you gave me for my advanced BlueBoard setup needs. As a musician, I needed some specifics things to make my live music, and I wasn’t able to code myself, as in this case Streambyter module was essential to achieve my goal. My main live rig depends now on this great MidiFire scene, I love it and it was really fun to do my part too:

    I don’t consider myself as a stupid guy. I’m certainly not, I’m able to elaborate complex art form or music setups, and I think I’ve got a good understanding of midi stuff including advanced routings.

    But I’m mostly an artistic guy, my brain works that way. You know, when I start using DAWS on desktop back in 2000, almost all my musicians friends wasn’t as hot as me on the topic and didn’t want to go that route, that wasn’t enough « musical » for them. I suppose that’s a reason why lot of musicians choose to mostly play their instruments or use hardware equipment.

    I can understand this coding language is extremely simple and easy from a coding perspective, but for a « non coding brain » it’s still unnatural and too different from emotional artistic approach. I don’t mean coders don’t feel emotions!!!! But lot of musicians are built this way.

    So I also think it’s about offer and demand, GUI friendly with « no coding needed » apps will still rule in musicians community. But as some of them, like me, still will have very specific and complex needs for their music achievement, MidiFire and such apps will always have their place as they allow IMO things which are not doable another way. This is where your offer, with your nice apps and coding help concept is a great answer to those musicians specifics demands. This is also why I gave 5 stars and a nice comment to MidiFire in the AppStore :)

    Cheers 🥂

  • Logic and emotion are the central pillars that enable us to traverse our course through life. Most people are fortunate enough to have a balance of logical and emotional thinking but some veer to the extremes at either end.

    Speaking in lazy stereotypes, that means that at one end you have the programmers that traverse life with logical thinking and at the other artists with a far higher EQ than IQ (EQ as in emotional intelligence).

    Much as that's a broad brush stroke description it plays out in any creative community I've ever been a member of. There are technical artists that find it hard to understand that even simple programmatic concepts are hard for some people to decipher. Whilst the purely EQ driven creative will often think 'but I'm an artist, not a technician'.

    And so it plays out time and time again.

    The important thing I suppose is to try and be cognisant of those differences when we interact with others in communities such as this.

    I'll now remove myself from my soapbox, so normal services may return. :)

  • @audeonic : I just want to say that I love your apps and your dedication to supporting your users. We are lucky to have you creating the apps you do.

  • @espiegel123 said:
    @audeonic : I just want to say that I love your apps and your dedication to supporting your users. We are lucky to have you creating the apps you do.

    :+1:

  • @jonmoore : your disclaimer notwithstanding , it seems like you are reenforcing the notion that scripters are somehow a different separate population from artists.

    To the extent that there is a divide, it isn't a logic/art dichotomy.

    It is true that some people look at anything programming or scripting like with horror and have an aversion to methodical thinking. Also true that methodologically inclined thinkers sometimes have difficulty understanding what it is that methodologically-averse people find intimidating .

    But those are vectors entirely independent of those related to artistic/creative sensibilities. To the extent that there is a divide, lots of artists can be found on both sides...and of course most people are somewhere in the middle.

  • @audeonic StreamByter allows me to use a sustain pedal for switching snapshots in my XR18 mixer, so I will always be grateful for it

  • edited April 12

    Thanks for your input (rant) Nic. ;)

    It was probably me who said that Streambyter wasn’t efficient. Well, not quite. I actually said that streambyter was less efficient than midifire. I might have been wrong in saying that but i was only quoting your good self.

    Now to the main dish.
    I’m not a coder and I never aspired to be one. It is not about being mega frightened by learning a new language since I so far managed four. It is more about setting priorities. I already do fair amount of fiddling in IOS as it is and rather leave technicalities to technicians. Having said that, I understand midi for what I need and I’m generally eager to learn beyond a certain point I just want to play. Not to play with plugs but more like actually play music (I know for some one equates to other). :)

    I’m with you there @TheVimFuego. I was thinking this just today: my two loves are music and construction (wood) how I understand you. When I’ve had enough ethereal, woodwork definitely swings it the other way. :)

    @audeonic I do know your not so legendary app support. In fact I made use of it and can assure everyone it isn’t legendary...it is real and absolutely amazing. The thing is though, I don’t want to have to spend time contacting support or forums to change CC to PC and vice versa. I want to just flick a box on the left and the one on the right and be done with it. Apple are quite good at this hence their success I guess. None of this is of course your fault but I guess I was born too early. :)

    If someone released an iOS soft synth where you need to insert a code in order to change a waveform it would get slaughtered by AppStore reviewers. Who could blame them? If Korg released their manuals only in Japanese I wouldn’t be stoked either. I know, extreme examples but all this just to say that ease of use and accessibility go a long way.

    And lastly...not leastly...thanks for your good work! :)

    I added a smiley for each paragraph just in case ;)

  • @supadom - yes, for many conversions, mfxConvert is your friend. However, in the case of the BopPad stuff where we needed to examine notes and CC's and piece things together using logic, generate and re-order events - I really don't know how you could make up a GUI to handle something like that. This is why StreamByter exists - to have some way of solving those crazy situations.

  • edited April 12

    @audeonic said:
    @supadom - yes, for many conversions, mfxConvert is your friend. However, in the case of the BopPad stuff where we needed to examine notes and CC's and piece things together using logic, generate and re-order events - I really don't know how you could make up a GUI to handle something like that. This is why StreamByter exists - to have some way of solving those crazy situations.

    I was talking about pc to cc blueboard code with which you have simplified lives of many.

    Edit. It actually wasn’t pc to cc originally but I needed that before that code since my FC50 doesn’t send CCs.

  • @audeonic said:
    When boiled down, the StreamByter language consists of just 5 simple commands, generic pattern matching and array variables:

    ASS - assign values to array variables
    SND - send a MIDI message
    MAT - perform a calculation
    IF/ELSE/END - conditionals and loops
    SET - configure labels and sliders
    [input MIDI message] = [output MIDI message] - rewrite a MIDI message using patterns

    array variables are just slots of memory (or special values like random, timing, current message or slider) that are used in the above rules.

    and that is it.

    The language is relatively strict in terms of syntax - this is to make it easier to parse.

    Totally appreciate what you do! I think you make amazing products and provide truly amazing support, so please don't take this a criticism, but more perspective from the other side!

    As someone whose job it is to sit at the intersection of creative and technical endeavors (and therefore make sure everyone's understanding each other), I recognize that having your language boiled down to 5 simple commands is a point of pride for an engineer in terms of its elegant simplicity and straightforward implementation and syntax.

    However, from the point of view of non-technical people, that fact that there are only 5 simple commands is part of their aversion! While many people can be trained to code, most will initially balk when presented with something that looks so foreign to them and requires them to break down their human-language-centric problem solving into simpler functional commands. This is the appeal of more "human-readable" languages; it breaks down the barrier to entry, because even non-programmers can get a sense of what's going on without too much thought. They won't "shut down" so quickly.

    It's also the appeal of graphical, node-based systems. These really work for people who have better spacial-logical reasoning than linguistically-centric or mathematical reasoning. This group includes many musicians.

    And at the end of the day, even the more technically inclined (including programmers) are often looking to get away from the programming mode of thought when they're trying to be freely creative. I can figure out what's going on, but when I'm trying to make music, my eyes tend to glaze over when looking at code!

    Regardless, as mentioned, thanks for making these tools - precisely because they're not for everyone!

  • edited April 12

    @audeonic - I feel like I called your baby ugly on the other thread and I feel bad about that. Sorry. I don't deny the utility of it, and you've written some great scripts using this. It is very powerful. But... and this is entirely personal, when I see something like this in the manual I just sigh:

    # filtering rules
       X1-F = XX +B # only pass channel 1
       NX = XX +B # block all note events
       BX = XX +B # block all controller events
       F8-C = XX +B # block all clock events
    
       # remapping rules
       XX = X0 # remap everything to channel 1
       N9 = X0 # remap notes on channel 10 to channel 1
       NX 24 = XX 28 # remap note C1 to E1
    

    Can I work this out? I'm sure I can, I've done assembler. But I know it won't be fun or quick, I'll have to translate Hex to decimal, remind myself of what N/X/B/F all mean. It's fairly cryptic, is not very readable, is pretty low level (that's what I was getting at with assembler - no loops, functions or variable names) and I will be constantly debugging things where I wrote the decimal version of a number rather than the Hex code.

    On the other hand maybe this is just prejudice on my part, and if I sat down and actually tried to write a script I'd feel differently. I do like writing assembler, even if I'm not particularly good at it.

  • I think people THINK they want one tool to do it all-- give them infinite flexibility and depth, simple elegant self-documenting user interface, and brilliant CPU-performance.

    The reality is: there won't be such a tool. Different tools and apps will be optimized for different aspects of people's needs.

    MidiFire/StreamByter is not a good fit for everyone. And that is ok. It is great at what it does.

    There are other tools that handle aspects of what it does. There will be more. But let's not look at MidiFire not being the tool for everyone be seen as a failing of MidiFire.

    I totally sympathize understand that for many people, its approach is just foreign to how they like to work. Nothing wrong with them for wanting tools that appeal to their way of working and nothing wrong with MidiFire not being that tool.

  • @espiegel123 said:
    I think people THINK they want one tool to do it all-- give them infinite flexibility and depth, simple elegant self-documenting user interface, and brilliant CPU-performance.

    No, 2 or 3 different tools are fine.

    Elegant would be nice but not absolutely essential.

    There are apps out there that are deep, yet easy to use.

    While on the spaced out side people here are generally pretty switched on, not 3 years old high on lactose.

    Likely any midi tool won't break any post ios7 device in terms of cpu/ram footprint.

    Just believe.

  • Whether you like these apps or not, there is no denying their potential power and usefulness.
    MidiFire can be used without scripting anything, as StreamByter is just one thing it does, among many.

    StreamByter AU shouldn’t put off non-coders, as it seems primarily meant to run scripts, not write them. If you can request a script or find an existing one that suits your purpose, and work out how to load and run it in SB AU, it is not hard at all. And you may find it very useful.

    There are all types of people doing iOS music. Some like the technical challenge of extending the existing tools with custom scripting, Some even wear the Developer hat as well as the musician/producer hats. But there are many people who just want something easy to use, like Figure or Gadget, and don’t even delve into modular DAW-less workflows that utilize AUM/AB3 and a whole list of plugins.

    There is a lot of exaggeration on this forum about how hard it is to use StreamByter. When I read negative comments about how StreamByter is too difficult, I figure the person was never able to leverage the app, and therefore never really used the app properly. If I try to learn to learn StreamByter and ultimately fail, that is on me. There are plenty of examples of people using it to create clever and useful solutions to various Midi routing conundrums, so it is definitely not the app’s fault.

  • We should never forget that there are developers that depend upon users to pay their bills.

    I'm going to repeat a lot of Nic's points from the point of view of an IOS App User that wants to see this product become more pervasive so we can get more solutions faster for MIDI headaches. Are you know there are a million MIDI headaches and a hundred product tools for them.

    Anyone with the skills to create IOS Products could be a programmer for a business and get the salary, benefits and job security. But a small group of developer's take the personal risk to be self-employed and handcraft products for us... looking for an area of the market no one services.

    Many programmer's try an IOS Product or 2 and just can't get the payback. It's sad when it happens but the risk of a small business. Micheal has said the #1 thing a develop needs is "luck".

    We could make a list of these folks that have given us:

    MidiFire/Streambyter
    Auria Pro
    Rozeta Suite
    AudioBus
    AUM
    AudioReverb

    From Nic's perspective Streambyter is easy to learn. Chess is too if you have the motivation
    to climb the learning curve. You won't win any tournaments but you could learn the rules and moves with some effort.

    StreamByter can perform magic that no other app can perform because its programmable.

    Nic and @_Ki have created point solutions in StreamByter code so users of the products don't need to code anything and get the benefits of a solution:

    NanoStudio doesn't respond to Sustain Pedals - @_Ki made a script to fix that. NOTE: It only works in MidiFire because StreamByter AU in NS2 doesn't expect to route to the internal synth. If NS2 users wanted that the developer of NS2 might be able to get around to fixing that. But loading @_Ki's script into MidiFire and sending the modified MIDI Stream in as the controller makes the sustain events work in NS2. It could be used for any polyphonic synth that wasn't built to perform sustain functions.

    Developer's can also see these requests and code solutions that solve that problem like
    keyboard split points, velocity curves, note to chord/scale conversions, etc.

    One came up this week: Is there an App that sends out a MIDI Panic (all notes off NOW!).
    So, I asked on the StreamByter Forum for a solution and got a script today that does it.
    Users will benefit because it's often hard to find the offending App that missed the Note Off.
    Developer's will see the solution and maybe sell us a Panic Button but a hand coded solution for me was created in a couple hours for me. Nic mentioned he might include it with the product as a factory preset.

    What StreamByter needs is a steady stream of MIDI problem requests and every point solution will result in a new product sale.

    When the AudioBus Knowledge Wiki is up and running we can start documenting these fixes here too.

    If you have a MIDI issue just ask for help and in many cases a workaround might be possible with StreamByter/MidiFire.

    The users learning curve could be as simple as "how do I import and run this script?" No programming required since there are people that will do it for you if it's an interesting problem.

    We buy a lot of GUI-based MIDI tools and Nic participates in that solution space too but
    MidiFire/StreamByter provides an infinite variety of solutions for the price of the App.

    When developers speak up here - give them total respect because so many won't deal with us. These Apps are their children and they will protect them from negative comments. Fair enough, I say.

  • @supadom said:

    If someone released an iOS soft synth where you need to insert a code in order to change a waveform it would get slaughtered by AppStore reviewers. Who could blame them?

    >

    https://itunes.apple.com/gb/app/bitwiz-audio-synth/id522046655?mt=8

  • @TheOriginalPaulB said:

    @supadom said:

    If someone released an iOS soft synth where you need to insert a code in order to change a waveform it would get slaughtered by AppStore reviewers. Who could blame them?

    >

    https://itunes.apple.com/gb/app/bitwiz-audio-synth/id522046655?mt=8

    Couldn’t you just keep it secret from the opposition?

  • @TheOriginalPaulB said:

    @supadom said:

    If someone released an iOS soft synth where you need to insert a code in order to change a waveform it would get slaughtered by AppStore reviewers. Who could blame them?

    >

    https://itunes.apple.com/gb/app/bitwiz-audio-synth/id522046655?mt=8

    That one slaughters you when you use it.
    Sometimes, getting slaughtered is great.

  • If someone released a Synth that would offer a text screen for you to add DSP routines
    and provided a dozen DSP examples it would get a lot of reviews about the code being
    hard to understand and a few that wonder why we need to read code when we can just
    pick DSP's off a GUI. But there would be this small group of folks that would make Digital Signal Processing scripts that would be unlike anything available.

    Programmable tools that save us the headaches of downloading Xcode and learning AudioKit and mastering that level of complexity are like "Jewels" among the rocks.

    There are examples in every application space to show StreamByter code as a true
    "game changer". The user can create new behavior from it's computer:

    Visicalc spreadsheets
    Basic Language

    Maybe Mosaic will help people climb the hill to make MIDI your bee-yotch. Right now it's
    got most of us under it's thumb.

  • wimwim
    edited April 12

    @McD said:
    If someone released a Synth that would offer a text screen for you to add DSP routines
    and provided a dozen DSP examples it would get a lot of reviews about the code being
    hard to understand and a few that wonder why we need to read code when we can just
    pick DSP's off a GUI. But there would be this small group of folks that would make Digital Signal Processing scripts that would be unlike anything available.

    SunVox. Audulus 3.

  • Is there a way to add code to SunVox? I missed that. I tried Audulus and gave up after all the demo’s Left me uninspired. But those are good examples of programmable products.

  • wimwim
    edited April 12

    @McD said:
    Is there a way to add code to SunVox? I missed that. I tried Audulus and gave up after all the demo’s Left me uninspired. But those are good examples of programmable products.

    Not in a programming language sense, but some of the advanced tracker concepts border on it ... and are even in Hex. B)

    Those were simply examples of apps that often excite certain technical types and turn off others for many of the same reasons.

  • @wim said:

    @McD said:
    Is there a way to add code to SunVox? I missed that. I tried Audulus and gave up after all the demo’s Left me uninspired. But those are good examples of programmable products.

    Not in a programming language sense, but some of the advanced tracker concepts border on it ... and are even in Hex. B)

    Those were simply examples of apps that often excite certain technical types and turn off others for many of the same reasons.

    Point taken on the "excite certain technical types" or as I call them, "smart people" while many call them Nerds. It has never been a better time to be a Nerd. So many opportunities
    to geek out and find community with someone across the globe who things it's cool too.

    So, are we cranking up the feeding frenzy for Mosaic yet?

    Let's move past scripting and request an Object Oriented Language for Audio Processing
    packaged as Stand-alone/AUv3 App and an SDE that uses Vi/Emacs text macros and sells for less than $10 - of course a GUI Code Builder as an IAP would be a nice extra to design the custom GUI's we would like. Too much nerd?

  • FYI: @_Ki made himself a pre-processor for StreamByter scripts so he could work out the
    algorythms in a pseudo code and generate the StreamByter version with his pseudo-code statements appearing as comments for each statement. Too bad he has a demanding day job because there's no *real* money servicing the needs of IOS Music Nerds... unless Jimmy Fallon uses your App on the TV several times and asks you to write another App to do a a segment.

Sign In or Register to comment.