Mac OS 9 Lives

Classic Mac OS Software => Digital Audio Workstations & MIDI Applications => Plugins (VST,TDM,RTAS,MAS) => Topic started by: Protools5LEGuy on March 19, 2023, 06:58:49 PM

Title: Pluggo & MAX & Motorola 56K
Post by: Protools5LEGuy on March 19, 2023, 06:58:49 PM
Do Pluggo / MAX let you develop TDM plugs or are all RTAS?
Title: Re: Pluggo & MAX & Motorola 56K
Post by: IIO on March 19, 2023, 07:27:07 PM
nope, rtas only.

i always wished they would run on powercore, haha. but you would have to rewrite all objects for that, not only the runtime.
Title: Re: Pluggo & MAX & Motorola 56K
Post by: Protools5LEGuy on March 19, 2023, 07:43:38 PM
Any idea where TDM SDK is?

I have been browsing on JUCE forums, the authors of traction and it seems for AAX you have to sign a contract with Avid and you HAVE to develop the plug.

RTAS SDK had a v9 guidelines and v8 version that you need to sign with Avid to get it.

Maybe Protools v3 and 4 had leaked docs. Or 5 or 6-7

Title: Re: Pluggo & MAX & Motorola 56K
Post by: Protools5LEGuy on March 19, 2023, 07:49:22 PM
https://juce.com/building-max-with-juce/ (https://juce.com/building-max-with-juce/)

Quote
Building Max with JUCE
David Zicarelli of Cycling ‘74 discusses building Max with JUCE

David Zicarelli is founder and CEO of Cycling’74, a software company developing Max, the digital signal processing software environment. For nearly ten years David has used JUCE to build and commercialize Max. In an interview with the JUCE team, David tells us about Max, his next steps for this highly sophisticated cross-platform interactive software, and the integral role of JUCE in facilitating it. “It’s so brilliantly designed it makes us write better code just to interact with it,” David says.

What is Max, and how did it start?
Max was born out of the desire to give musicians and artists the ability to create software using intuitive interactive tools. It was a way to remove the limitations of traditional music software without forcing musicians to learn to code.

Max is now a complex environment with hundreds of different types of objects covering a wide variety of applications. But we try to maintain a simple idea: everything can be controlled with a simple stream of numbers. When everything is a stream of numbers, it means any kind of media or controller can talk to any other kind of media or controller. What’s happening under the hood can be very complex with protocols, operating system drivers, or hard math. But to the Max user it’s just numbers going from one place to another. This lets you control audio parameters with a user interface, an LFO, data from the internet, or even another program you write in one of many languages.

We have three main customer groups starting with universities. Max is taught in universities all over the world. Max started in music, but it’s increasingly used in art and architecture programs. Our users are also individual practicing artists and musicians who develop their work in the software. They might use Max to build an installation or a system for live performance with the software. Third, we’ve worked with Ableton on “Max for Live,” which is a way to extend Ableton Live – their DAW – in all sorts of cool ways. Max for Live could also be thought of as Live for Max, in that whatever you make with Max you can use Live to automate or compose with.

What were the challenges developing Max?
We share the challenges of any complex software application written over decades with millions of lines of code. In other words, what isn’t a challenge?

But more seriously, we have to understand the nature of a wide variety of disciplines and technologies well enough to figure out ways to make them easy for artists but still broadly programmable. Inevitably this leads to tricky compatibility issues. The underlying world keeps evolving, yet the model we present to users needs to stay relatively stable.

Another difficult challenge is that performance problems are almost impossible to anticipate, as they arise from what users do. Our performance problems are not just about the absolute time it takes to do something. They are also about balancing responsiveness with processing power. With a traditional DAW you can compute a lot of what happens in advance because you’re playing a set sequence of events. But in Max, anything could happen at any time; you can’t predict what someone will do to an interactive piece. Yet at the same time, people expect Max to do as much stuff as they can in software that is not so spontaneous and interactive. Sometimes it doesn’t feel fair!

What made you choose JUCE?
To me, the reasons for choosing JUCE are less important than our experiences over the past nine years that have made us so happy with JUCE. How we use it is a bit unusual. Unlike most software that has been written with JUCE, we didn’t start from scratch. We used JUCE to rewrite large parts of Max from its old and clunky OS-specific style. To do this, we had to build a layer on top of JUCE that talked to the part of our software we couldn’t change. We used this layer to rebuild our user interface, but at a higher level we made Max objects out of pieces of JUCE. There’s an object in Max called jit.cellblock, for example, that lets you display data in a spreadsheet-like form. This object is actually a subclass of a JUCE TableListBox. There are many Max objects wrapping other parts of JUCE that we use to build the actual UI of the software. I suspect someone familiar with JUCE could look at Max and figure out what classes all of these secret objects use.

Sometimes we use JUCE as a kind of glue to put our own lower-level stuff into the rest of the application. For example, in our new version Max 7, we’ve created a CEF container to display web content inside a Component. This lets users build interfaces that combine web technology and our more traditional JUCE-based interface elements. Everything acts as a Component and plays together. I don’t really know how this is even possible, but it works! We use JUCE as a modular structure to organize our low-level work as well as a way to abstract platform dependencies. It is so brilliantly designed it makes us write better code just to interact with it.

How did you come across JUCE?
Max started its life as a Mac-only program back in the 1980s. As it became increasingly complex, we wanted to port it to Windows so we licensed a library called Mac2Win that essentially emulated the Mac OS on Windows. ProTools was also ported to Windows using this library, by the way. This library was very expensive, and it ported the pre-OS X version of the Mac OS, so about ten years ago we started looking for another cross-platform option. A coworker found out about JUCE, and within a few days he had an example of how it would work for us.

Tell us more about Max 7.
With our new version, we’ve focused on ways we can make Max feel simpler. For example, you can just drag and drop media files to play them now, instead of having to know about the objects that do it. We’ve also simplified and modernized the user interface fairly radically.

What are the next steps for Cycling ‘74 in terms of Max and Gen?
Increasingly our customers want to build software for a variety of contexts and environments beyond the desktop. That’s why I’m excited about Gen as a forward-looking technology [that we’re developing].

Gen is a way to create high-performance audio and video processing using a graphical interface. It looks like Max, but the underlying implementation is entirely different. Instead of the user interface manipulating data to implement your program, Gen writes out a little C++ program, compiles it, and executes it each time you make a change. This means you can “code” interactively while listening to what your algorithm does. If you want to use that algorithm in other software, you can export it to C++ code that has no dependencies on Max itself. In Gen, you are describing how a single sample of audio will be processed or synthesized. We take care of everything else that turns that sample algorithm into optimized audio code.

That Mac2Win library seems intriguing.
Title: Re: Pluggo & MAX & Motorola 56K
Post by: IIO on March 19, 2023, 08:06:05 PM
both RTAS and TDM never was open and i´ve never seen it anwhere.

i would think it is the opposite way: for AAX you might find someone sharing his material, but you can not do more with it than programming stuff for yourself. if you publish it without consent, the homeland security special ops visits tomorrow.

for OS9 the number of license takers is below 40(!), of which at least 1 company owner is a scene member. but professionals will have that kind of vintage stuff deleted from their drives long ago.^^

then, as you know, nore more VST2 publishing is allowed unless your registration is older than 10/2018 or whenever that was.

for pluggo you do not need licensing of VST, RTAS, MAS, AU, it was already given to cycling runtime.

same with VSTs containing RNBO code made with max - unless you distribute commercially.

MAS was open like VST, but support and format is long dead.
Title: Re: Pluggo & MAX & Motorola 56K
Post by: IIO on March 19, 2023, 08:07:39 PM
since that press release everyone thinks "max is made with juce", but it is not really. :P
Title: Re: Pluggo & MAX & Motorola 56K
Post by: Protools5LEGuy on March 20, 2023, 06:45:20 AM

i would think it is the opposite way: for AAX you might find someone sharing his material, but you can not do more with it than programming stuff for yourself. if you publish it without consent, the homeland security special ops visits tomorrow.

for OS9 the number of license takers is below 40(!), of which at least 1 company owner is a scene member. but professionals will have that kind of vintage stuff deleted from their drives long ago.^^



Developers are the opposite thing to Mac OS 9 DAW users.

They try to stay in the latest dev environment.

We try to stay on Mac OS 9.

Did that company owner develop TDM stuff?
Title: Re: Pluggo & MAX & Motorola 56K
Post by: rvense on March 20, 2023, 11:46:01 AM
Well, I'm a developer that isn't really all that interested in new things. And there are plenty of people who like both the old and the new, there's lots of new stuff developed for other platforms, and these past few years there's been a lot more hardware hacking and projects, including full board recreations.

Personally, I would really like to find the old MOTU SDKs, they appear to have handed them out more liberally than Digidesign did theirs. The 56k assembly you need to do TDM plugins looks hard to do properly though.
Title: Re: Pluggo & MAX & Motorola 56K
Post by: teroyk on March 21, 2023, 01:52:34 AM
Personally, I would really like to find the old MOTU SDKs, they appear to have handed them out more liberally than Digidesign did theirs. The 56k assembly you need to do TDM plugins looks hard to do properly though.

It would be nice to find. 56k assembly is not harder than any another assembly, that DSP-chip was inside Atari Falcon and some Atari sites has complete information about it.
Title: Re: Pluggo & MAX & Motorola 56K
Post by: smilesdavis on March 21, 2023, 02:00:07 AM
Well, I'm a developer that isn't really all that interested in new things. And there are plenty of people who like both the old and the new, there's lots of new stuff developed for other platforms, and these past few years there's been a lot more hardware hacking and projects, including full board recreations.

Personally, I would really like to find the old MOTU SDKs, they appear to have handed them out more liberally than Digidesign did theirs. The 56k assembly you need to do TDM plugins looks hard to do properly though.

Id buy new atari falcon and pro tools iii nubus & pci plugins