Many people learned, for example, JavaScript simply because they wanted to improve their Max patching, so Max can serve you as a starting point to get into programming in general if you like, but only if you like. Numerous programming languages such as JavaScript, Java, Python, and others can be used within Max if we believe that a task requires these or is simply achieved quicker or better with a different approach than patching.
Max msp jitter video Patch#
Think of it like a basis, an infrastructure where you can not only patch but also embed text-oriented programming very easily. The real power of Max is in its modularity. For multimedia programming, Max is very close to this objective. A good tool for a certain task allows us to control all parameters that are of any interest for a certain task, not less and not more. We usually don't want to deal with memory allocation when our aim is to quickly build a synthesizer, for example. We lose some control over what's actually happening, but there are lots of things we don't want to see and don't want to care about in typical multimedia programming.
Max msp jitter video code#
The details of this are both an advantage and a disadvantage of Max, but often, we won't care about the code itself. You can think of Max as a high-level programming language in which we put together code we don't quite know. There are some special cases, namely the gen domain, which we will see in Chapter 6, Low-level Patching in Gen, in which we can actually see and also export the code that Max is creating from our visual programming. We saw that Max can create code for us that looks very much like C++. This, for example, looks much like our mathematical representation and does not provide us with an impression of the order of operations as quickly as a Max patch does: A traditionally coded program doesn't need to be that way. We always go from the outlets of an object to the input of another, typically using a line, going from top to bottom. A Max patch has the advantage that the flow of data is always obvious. They tell us what to do with the input so as to get the output. Code, Max patches, and written recipes, on the other hand, are always imperative. On the other hand, mathematical expressions that describe a system can be declarative (meaning not giving us a recipe to get from the input to output but only describing a relation as it's the case for differential equations). A mathematical expression is concise and precise. Text (a recipe that explains what to do in natural human language)Įach one of them has its strengths and weaknesses. Let's add another equation for reference:ĭata flow (Max patch) / block diagram (as in our patcher depicted previously) In essence, these sentences are like a recipe for cooking. By now, you have seen two representations of what's happening the last few sentences describe what's happening in the patcher and the patcher itself. The program we see here doesn't do anything very useful, but it will hopefully illustrate differences in representing mathematical operations. Afterwards, we subtract 0.2 and get 0.3, which will be sent to the output of our little patcher.
Then, we multiply it with 0.5 (or divide it by 2), resulting in 0.5. You can see that first, we add 1 to our incoming number, resulting in 1.
Can you already see what's happening? Imagine a number, say 0, coming into our patcher at. So, don't try to implement this right away we'll have a slightly theoretical start for now. However, this gen~ patcher is using a somewhat different vocabulary (object names). It is also called a gen~ patcher, and we use it here since it allows us to see the code generated under the hood. Don't bother about the vocabulary, that is the object names, too much.
0 kommentar(er)
