MSG V4 Processor Breakdown Information

Bernard was kind enough to put together this excel spreadsheet with information about all of the mSG processors in Studio Artist V4.

It breaks them down by their IO routing.

And perhaps he can comment some more.

I don't have Microsoft Office Excel on my computer right now, so i can't look at it directly. But he asked me to pass it on for people to download, and it is currently being discussed and examples of it shown in this image post.

Let me know if i need to zip compress it, i just tried attaching it first below.


You need to be a member of Studio Artist to add comments!

Join Studio Artist

Email me when people reply –


  • Here's the old MSG Evolver Guide pdf. From Studio Artist 3.5. When we had a completely separate application dedicated to MSG editing called MSG Evolver. There is a lot of explanation in this MSG Evolver User Guide about what is going on under the hood of MSG.

    You can thank Apple Computer for their great love of their customers and their great love of maintaining backwards compatibility with old programs that used to run on their platform. Of wait, maybe i got that backwards. Because they are directly responsible for preventing you from being able to running MSG Evolver on any modern Apple Computer. Because technically, there is no reason why rosetta emulation could not continue to run on all modern Apple computers with the latest versions of osx. They just decided to shut it down as a marketing ploy to force people to be unable to use old apple software.

    As a small company, we had to make a decision with Studio Artist V4, and we really didn't have the resources to continue the development of 2 separate programs that had to be rewritten from scratch, since Apple went out of their way to force us to rewrite them from scratch. So that's why all the MSG editing is inside of Studio Artist now. You can probably sense my frustration, because i would love to be able to continue to run MSG Evolver, and to continue the development of it's original code base. Let alone people who have old data from other old programs they might need to be able to access, but cannot unless they keep some really old computer around (with a really old os version running on it) to run the software. Something Craig actually does do, because some old drawing programs he loves to use will only run if he does that.

    So there's my little rant, and i hope you find the information in the MSg Evolver Users Guide that deals with the inner workings of MSG useful. It explains things like Tmp Img streams and why they are there.

  • I join you the processor files in pdf. Sure that it was adapted to my printer. So you'll find a complete list with and without borders so you can reconstruct yourself with excel files.

    As you can imagine, it took me about 15 jours to made this list...

    But MSG is a great tool, as the vectorizer or the paint synthesizer are. And I found it necessary to learn how they work. As a technician, I like to know what is in it. So actually when I use the MSG, I work on a paper, and draw it as a technical diagram, begin with a generator, then Input output processor, etc...

    Then I realize it with SA. I open also the evolution editor : to have variations of the created preset.

    Sometimes, when I found an interesting  'inspire mode generated preset', I analyze what each processor do. And here my list is a good help ! 

    Remember also, that you can add paint effects if you choose the following set up in the MSG editor, composite output :


    And in the paint synthesizer editor :


    Hope you'll have fun, as I have...If you have any questions, we can all help you !


    • Thanks very much Bernard!!

    • when I use the MSG, I work on a paper, and draw it as a technical diagram, begin with a generator, then Input output processor, etc...

      You can tell us more? 

      Diagrams, scheme?

    • Quick example of an MSG preset of hat I mean. I draw this on a paper because it's faster. Here I draw it with a software, so that you can see it better


    • What is:

      In Tex

      Tmp Img


      In Orient

      Where to go next:

      R Out

      G Out

      B Out

      what is the inner logic MSG`s? Diagrams, scheme?


      Thanks a lot!

    • you'll find answers here in the studio artist folder:


    • We've thought about making the IO editor part of the MSG advance editor more visually sophisticated. Kind of more like Bernard is suggesting above. So you'd see the full set of Bus connections visually, and all of the IO connections associated with the processor (from the Bus to the processor IO ports, and then back to the Bus again).

      Because the way it is now, you do have do that full visualization in your head, since you just work with and see one IO connection at a time in the IO editor panel. Associated with just the currently selected processor.

      The advantage of our existing approach is that it's very space efficient.

      If we add a more sophisticated visual component, it will take up a much larger amount of real estate on the screen. But i do think it could make IO editing way easier for mere mortals.

      i can do the visualization in my head, but i probably seem like Spock or the Borg to most people, kind of a severe tech geek.

      Now, Bernard also showed an alternative nodal modular system below. And these kinds of nodal systems internally are using what a computer scientist would call a tree structure (as opposed to a list like we use) to define the overall modular processing architecture.

      Would it make sense for MSG to be edited with a nodal editor?

      Every time i think it through, i come to the same conclusion, it would actually be a really bad idea. For 2 reasons.

      The order of individual module processing in a nodal editor is oftentimes not obvious to the person doing the editing. usually it involves some kind of left to right, up to down module positioning rules. But it's often times kind of unclear. What is the order of execution for the individual modules?

      This is very important in MSG. Changing the order of execution of the individual processors could totally change the effect it was producing. So if you dragged the nodal modules in that editor to different positions in the 2d visual image, even though they are connected exactly the same, the effect they would generate could actually change. It certainly would be the case if you were editing MSG that way. So that would be very confusing to people.

      Seeing the MSG processors positioned in a list, and editing them that way (in a list), makes that processing order very clear. The individual processors are executed in order, one by one, from top to bottom in the list. So they work like every other list in Studio Artist, the individual steps are run in order, from top to bottom. Consistent behavior across the entire interface of Studio Artist.

      There is no confusion about it when the processors are edited in a list editor.

      It's inherently obvious, because you see and visually edit the processors in a list.

      Second, MSG works very different internally than a typical nodal tree-based module data structure that these other nodal modular editors use. They work by running the complete nodal tree-based processing on individual pixels, one at a time. So each individual pixel is processed through the entire tree-structure of modular processes. Then the program moves to the next pixel and does the same thing.

      Or another system of this type might use a very small buffer of pixels to try and speed this up, since what i just described could be very inefficient speed wise. So they use a buffer of 16 or 32 pixels, and run that through the tree structure of individual modules. Then repeat that process until they get through all of the pixels in the complete image for the processing.

      But MSG works with complete image buffers as it does it's processing. Each individual MSG processor takes in a complete image (or set of images), does it's processing on those complete images, and then outputs a complete set of images, or set of images.

      So, if we let people construct any old nodal processor tree they wanted to, they would probably construct some real crazy complex ones pretty quickly. And then the software would have to translate that tree structure into an actual list for processing. And we would then have to internally create all kinds of additional temporary full image buffers to pull that off. Because the nodal editing structure and how MSG really works internally would require it. Which could be a huge memory inefficiency.

      The way it works now it's very clear what is happening. How many image stream buffers are being used. And you can reuse them very efficiently across the full set of processors that generate the complete MSG preset effect.

      So nodal tree based modular editors would allow a user to get into trouble very easily, and the actual order of module processing would be very confusing to understand in that kind of editor.

      Because these other nodal system work the way i described, it's trivial for them to create little keyframe views of their processing at each module's output, since they are actually processing individual pixels, or very tiny image chunks. It's a little more involved for us.

      Adding a way to see the individual output of each processor would be very useful, and we have thought about it.

      Our thinking was more along the lines of some way that would allow you to select individual processors in the processor chain editor,and then see what they were outputting in the preview view. As opposed to the preview just always outputting the final complete effect processing.

      i use the mute checkboxes to do that kind of visualization manually now. With maybe an extra 1to3 processor i temporarily turn on of off as i do this individual processor output visualization. but a nice easy to use way to do it automatically would be much better.

This reply was deleted.