carl_lofgren@yahoo.com

Hi - seriously thinking about buying Max/MSP, but there are some things in my head that needs to be straightened out.

1) Copy protection. iLok. Is this a must? I have no problems with dongles - my Syncrosoft Cubase dongle is working great. Just heard lots of nasty words about the iLoks.

2) Exporting. In what formats can you export your creations in? I think I read VST and standalone on the site - but, I need to be sure before I click that buy-button.

3) Pluggo. Now this is something that confuses me a lot. Many times when I downloaded stuff made by what I assume to be Max/MSP, you always have to have the Pluggo runtime installed as well. Is this written in stone, and must be for everything you export? Personally I would like my creations to be as self-contained as possible - but if not - no biggie. Can live with that.

4) (ok - I lied) MIDI out. Is it possible to make a MIDI only plugin (VST) that outputs a stream of MIDI that can be used on other software synthesizers? I am thinking of step sequencers primary here.

three-stupid-questions

Am 02.12.2007 um 01:59 schrieb Carl Lofgren:

> Hi - seriously thinking about buying Max/MSP, but there are some 

> things in my head that needs to be straightened out.

> 1) Copy protection. iLok. Is this a must? I have no problems with 

> dongles - my Syncrosoft Cubase dongle is working great. Just heard 

No, you can authorize the software to your hard drive. No iLok is 

necessary -- it's just offered as a convenience for those who prefer 

> 2) Exporting. In what formats can you export your creations in? I 

> think I read VST and standalone on the site - but, I need to be sure 

Standalone, VST and 'Collective' (which is everything you need to run 

the patch using the Runtime version of the application). BTW, 30 days 

demo! You can try this stuff out without buying it immediately.

> 3) Pluggo. Now this is something that confuses me a lot. Many times 

> when I downloaded stuff made by what I assume to be Max/MSP, you 

> always have to have the Pluggo runtime installed as well. Is this 

> written in stone, and must be for everything you export? Personally 

> I would like my creations to be as self-contained as possible - but 

> if not - no biggie. Can live with that.

If you're not building plugs, you don't generally need pluggo.

> 4) (ok - I lied) MIDI out. Is it possible to make a MIDI only plugin 

> (VST) that outputs a stream of MIDI that can be used on other 

> software synthesizers? I am thinking of step sequencers primary here.

This has to be supported by the plugin host. If it is, then there 

should be no problem (my more plug-in savvy colleagues might have to 

correct me, though). From the PluggoDevGuide - "The ability to receive 

MIDI output from a plug-in may not be available in

your host application (e.g. Pro Tools and Live)."

We have some fun stuff in the works, too!

>
> Hi - seriously thinking about buying Max/MSP, but there are some  
> things in my head that needs to be straightened out.
>
> 1) Copy protection. iLok. Is this a must? I have no problems with  
> dongles - my Syncrosoft Cubase dongle is working great. Just heard  
> lots of nasty words about the iLoks.

No, you can authorize the software to your hard drive. No iLok is  
necessary -- it's just offered as a convenience for those who prefer  
them.

> 2) Exporting. In what formats can you export your creations in? I  
> think I read VST and standalone on the site - but, I need to be sure  
> before I click that buy-button.

Standalone, VST and 'Collective' (which is everything you need to run  
the patch using the Runtime version of the application). BTW, 30 days  
demo! You can try this stuff out without buying it immediately.

> 3) Pluggo. Now this is something that confuses me a lot. Many times  
> when I downloaded stuff made by what I assume to be Max/MSP, you  
> always have to have the Pluggo runtime installed as well. Is this  
> written in stone, and must be for everything you export? Personally  
> I would like my creations to be as self-contained as possible - but  
> if not - no biggie. Can live with that.

> 4) (ok - I lied) MIDI out. Is it possible to make a MIDI only plugin  
> (VST) that outputs a stream of MIDI that can be used on other  
> software synthesizers? I am thinking of step sequencers primary here.

This has to be supported by the plugin host. If it is, then there  
should be no problem (my more plug-in savvy colleagues might have to  
correct me, though). From the PluggoDevGuide - "The ability to receive  
MIDI output from a plug-in may not be available in
your host application (e.g. Pro Tools and Live)."

>>1) Copy protection. iLok. Is this a must?

>No, you can authorize the software to your hard drive. 

>No iLok is necessary -- it's just offered as a convenience

>>2) Exporting. In what formats can you export your

>>creations in? I think I read VST and standalone on

>>the site - but, I need to be sure before I click

>Standalone, VST and 'Collective' (which is everything

>you need to run the patch using the Runtime version

>of the application). BTW, 30 days demo! You can try

>this stuff out without buying it immediately.

Demo downloaded. Will install as soon as I have some serious free time to dive into it.

>>3) Pluggo. Now this is something that confuses 

>>me a lot. Many times when I downloaded stuff

>>made by what I assume to be Max/MSP, you always

>>have to have the Pluggo runtime installed as well.

>>Is this written in stone, and must be for everything

>>you export? Personally I would like my creations to be as >>self-contained as possible - but if not - no biggie.

>If you're not building plugs, you don't generally need 

Ah. So, IF I am building plugins, I will need Pluggo? And the Pluggo runtime will be needed install if I distribute my plugs?

Now, why is this? As I said - everytime I installed anything that required the Pluggo runtime, I felt a slight annoyance that a step like that had to be taken. But also as I said - no huge deal. But just curious why.

>This has to be supported by the plugin host. If it is,

>then there should be no problem (my more plug-in savvy >colleagues might have to correct me, though). From the >PluggoDevGuide - "The ability to receive MIDI output from

>a plug-in may not be available in your host application

A big thanks for this. Sounds like it will work well with other hosts then, such as Cubase.

By risk of getting myself banned straight away - I am going to ask the question that might irritate you guys and think I'm a bloody ignorant person. But may be true, as I am complete new to this developing tool.

Ok - here goes. Why Max/MSP. Why not SynthEdit? Or SynthMaker. I know Max/MSP is cross platform. But compared to the pricing - there is a slight difference. $50 for SynthEdit. $255 for SynthMaker. I think I know the answer, but I'd rather have them confirmed than eding up with the wrong kind of software.

>>1) Copy protection. iLok. Is this a must?
>No, you can authorize the software to your hard drive. 
>No iLok is necessary -- it's just offered as a convenience
>for those who prefer them.

>>2) Exporting. In what formats can you export your
>>creations in? I think I read VST and standalone on
>>the site - but, I need to be sure before I click
>>that buy-button.
>Standalone, VST and 'Collective' (which is everything
>you need to run the patch using the Runtime version
>of the application). BTW, 30 days demo! You can try
>this stuff out without buying it immediately.

>>3) Pluggo. Now this is something that confuses 
>>me a lot. Many times when I downloaded stuff
>>made by what I assume to be Max/MSP, you always
>>have to have the Pluggo runtime installed as well.
>>Is this written in stone, and must be for everything
>>you export? Personally I would like my creations to be as >>self-contained as possible - but if not - no biggie.
>>Can live with that.
>If you're not building plugs, you don't generally need 
>pluggo.

>>4) MIDI-Out
>This has to be supported by the plugin host. If it is,
>then there should be no problem (my more plug-in savvy >colleagues might have to correct me, though). From the >PluggoDevGuide - "The ability to receive MIDI output from
>a plug-in may not be available in your host application
>(e.g. Pro Tools and Live)."

By risk of getting myself banned straight away - I am going to ask the question that might irritate you guys and think I'm a bloody ignorant person. But may be true, as I am complete new to this developing tool.
Ok - here goes. Why Max/MSP. Why not SynthEdit? Or SynthMaker. I know Max/MSP is cross platform. But compared to the pricing - there is a slight difference. $50 for SynthEdit. $255 for SynthMaker. I think I know the answer, but I'd rather have them confirmed than eding up with the wrong kind of software.

Am 02.12.2007 um 09:58 schrieb Carl Lofgren:

> Ah. So, IF I am building plugins, I will need Pluggo? And the Pluggo 

> runtime will be needed install if I distribute my plugs?

> Now, why is this? As I said - everytime I installed anything that 

> required the Pluggo runtime, I felt a slight annoyance that a step 

> like that had to be taken. But also as I said - no huge deal. But 

I believe that you only need it to USE Pluggos, not to develop them. 

The run environment (the version of Max running in your DAW) is 

distinct from the MaxMSP app, which is generally a good thing.

>> This has to be supported by the plugin host. If it is,

>> then there should be no problem (my more plug-in savvy >colleagues 

>> might have to correct me, though). From the >PluggoDevGuide - "The 

>> a plug-in may not be available in your host application

> By risk of getting myself banned straight away - I am going to ask 

> the question that might irritate you guys and think I'm a bloody 

> ignorant person. But may be true, as I am complete new to this 

You'll never get banned for asking questions in a constructive way! 

Banning is a last-resort response to unmanagable, disruptive behavior. 

Calling the validity of our work into question is no big deal. :)

> Ok - here goes. Why Max/MSP. Why not SynthEdit? Or SynthMaker. I 

> know Max/MSP is cross platform. But compared to the pricing - there 

> is a slight difference. $50 for SynthEdit. $255 for SynthMaker. I 

> think I know the answer, but I'd rather have them confirmed than 

> eding up with the wrong kind of software.

MaxMSP is not just about making synths or plugins -- quite to the 

contrary! It's a programming environment for building all kinds of 

media tools - custom video or audio processing chains, performance 

interfaces, installations, alarm systems, etc. We happen to think that 

this flexibility is worth the extra money! If all you are doing is 

programming audio instruments for use in VST plugins, we still believe 

that our solution is pretty awesome. You certainly have more options 

in this case, though. Try out the competition: if you can do 

everything that you want for $50, I know what I would do. If you think 

that there's more that you will want to do, now or in the future, 

> Ah. So, IF I am building plugins, I will need Pluggo? And the Pluggo  
> runtime will be needed install if I distribute my plugs?
>
> Now, why is this? As I said - everytime I installed anything that  
> required the Pluggo runtime, I felt a slight annoyance that a step  
> like that had to be taken. But also as I said - no huge deal. But  
> just curious why.

I believe that you only need it to USE Pluggos, not to develop them.  
The run environment (the version of Max running in your DAW) is  
distinct from the MaxMSP app, which is generally a good thing.

>>> 4) MIDI-Out
>> This has to be supported by the plugin host. If it is,
>> then there should be no problem (my more plug-in savvy >colleagues  
>> might have to correct me, though). From the >PluggoDevGuide - "The  
>> ability to receive MIDI output from
>> a plug-in may not be available in your host application
>> (e.g. Pro Tools and Live)."
>
> By risk of getting myself banned straight away - I am going to ask  
> the question that might irritate you guys and think I'm a bloody  
> ignorant person. But may be true, as I am complete new to this  
> developing tool.

You'll never get banned for asking questions in a constructive way!  
Banning is a last-resort response to unmanagable, disruptive behavior.  
Calling the validity of our work into question is no big deal. :)

> Ok - here goes. Why Max/MSP. Why not SynthEdit? Or SynthMaker. I  
> know Max/MSP is cross platform. But compared to the pricing - there  
> is a slight difference. $50 for SynthEdit. $255 for SynthMaker. I  
> think I know the answer, but I'd rather have them confirmed than  
> eding up with the wrong kind of software.

MaxMSP is not just about making synths or plugins -- quite to the  
contrary! It's a programming environment for building all kinds of  
media tools - custom video or audio processing chains, performance  
interfaces, installations, alarm systems, etc. We happen to think that  
this flexibility is worth the extra money! If all you are doing is  
programming audio instruments for use in VST plugins, we still believe  
that our solution is pretty awesome. You certainly have more options  
in this case, though. Try out the competition: if you can do  
everything that you want for $50, I know what I would do. If you think  
that there's more that you will want to do, now or in the future,  
MaxMSP offers some room to grow.

> MaxMSP is not just about making synths or

> plugins -- quite to the contrary! It's a

> programming environment for building all

> interfaces, installations, alarm systems,

> flexibility is worth the extra money! If

> still believe that our solution is pretty

> awesome. You certainly have more options

> in this case, though. Try out the competition:

> if you can do everything that you want for $50,

> I know what I would do. If you think that

> there's more that you will want to do, now or

> in the future, MaxMSP offers some room to grow.

Thanks for your opionins. I really value them. The last thing you said interests me a lot actually. So basically Max/MSP is a visual programming environment, with a focus on sound and visuals? But you can do other applications as well. Am I correct? Then the natural question that follows is - where goes the limit? Of course I am not out to make a new Word, or OS. But sometimes it's handy to make small utilities yourself. Hmm... I just remembered my early Flash (v2) programming days. I found that really cool tool that could make a Flash movie into a screensaver. That was lots of fun - possible to do that with Max/MSP?

Uh. When reading the last I wrote, please don't get me wrong. I am just trying to understand the limits of Max/MSP. I do not have a huge desire of being the next Bill Gates of screensavers.

> MaxMSP is not just about making synths or
> plugins -- quite to the contrary! It's a
> programming environment for building all
> kinds of  media tools - custom video or
> audio processing chains, performance 
> interfaces, installations, alarm systems,
> etc. We happen to think that this
> flexibility is worth the extra money! If
> all you are doing is programming audio
> instruments for use in VST plugins, we
> still believe that our solution is pretty
> awesome. You certainly have more options
> in this case, though. Try out the competition:
> if you can do everything that you want for $50,
> I know what I would do. If you think that
> there's more that you will want to do, now or
> in the future, MaxMSP offers some room to grow.

Quote: carl_lofgren@yahoo.com wrote on Sun, 02 December 2007 00:58

----------------------------------------------------

> IF I am building plugins, I will need Pluggo?

No, Max can build Pluggo plug-ins even if you don't have Pluggo. Then you just need the runtime to run them.

> Now, why is this? As I said - everytime I installed anything that required the Pluggo runtime, I felt a slight annoyance that a step like that had to be taken. But also as I said - no huge deal. But just curious why.

Not sure why it's required, but at least it decreases the size of the plugin. Otherwise you'd need the Max+Pluggo runtime bundled up in every plugin you make. Although installing Pluggo runtime is a bit of an annoyance, it is a one time thing (until the next Pluggo version at least). And if you start releasing plug-ins on a web site one day, you'll save on bandwidth if they get popular :)

> >This has to be supported by the plugin host. If it is,

> >then there should be no problem (my more plug-in savvy >colleagues might have to correct me, though). From the >PluggoDevGuide - "The ability to receive MIDI output from

> >a plug-in may not be available in your host application

> A big thanks for this. Sounds like it will work well with other hosts then, such as Cubase.

Not sure about Cubase, someone else should be able to answer that for you.

Even if your DAW doesn't support it (or you are using AUs on a Max where this doesn't work) it may not actually matter. I like generating MIDI in Max and sending it over to Logic's synthesizers. This is easy enough to do with virtual MIDI ports, and in fact I prefer to send it from the Max application instead of a plug-in because I often rework my patch inside of Max as I'm playing music with it. That's actually one of the best things about Max - you can change your patch while it's running and experiment.

With plug-ins, virtual Ins/Outs/MIDI ports, rewire, or even ethernet, there are enough options for sending MIDI and audio signals between apps that you should be able to find something that works in your setup. That said, if you have a specific setup you want to work with, make sure you try it out during the demo period. Things don't always go so smoothly (in my setup I can't send audio from Logic back into Max while sending MIDI without some massive problems, but I don't really need this capability for what I want to do so it's ok).

> So basically Max/MSP is a visual programming environment, with a focus on sound and visuals? But you can do other applications as well. Am I correct? Then the natural question that follows is - where goes the limit?

That's a very good question. If you try to build really large complex applications you are going to hit some walls. Max is really great for experimenting and prototyping, and there is a huge amount of value in that. I'd say it's good for making tools and utilities and smaller applications. But it is probably not a good choice for large, complex applications. The main issue is that it has all the power of a full-fledged programming environment, but it doesn't have any of the structure of a normal text-based language that facilitates scalability and maintenance (does that make sense?). Also, it's not going to replace a command shell or a scripting language, because you can't run a Max "script" from the command line. You need to open the Max GUI environment to do anything.

There are people working on extensions that should make large application building easier, and some upcoming Max 5 features will help too. I've also found that when I hit the limitations, I can usually rework a chunk of my Max patch into a custom Max object written in C or Java, and then keep going a bit further. So it depends on how much effort you are willing to put in.

Quote: carl_lofgren@yahoo.com wrote on Sun, 02 December 2007 00:58
----------------------------------------------------
>  IF I am building plugins, I will need Pluggo?  

> >>4) MIDI-Out
> >This has to be supported by the plugin host. If it is,
> >then there should be no problem (my more plug-in savvy >colleagues might have to correct me, though). From the >PluggoDevGuide - "The ability to receive MIDI output from
> >a plug-in may not be available in your host application
> >(e.g. Pro Tools and Live)."
>
> A big thanks for this. Sounds like it will work well with other hosts then, such as Cubase.

Not sure about Cubase, someone else should be able to answer that for you. 

Even if your DAW doesn't support it (or you are using AUs on a Max where this doesn't work) it may not actually matter. I like generating MIDI in Max and sending it over to Logic's synthesizers. This is easy enough to do with virtual MIDI ports, and in fact I prefer to send it from the Max application instead of a plug-in because I often rework my patch inside of Max as I'm playing music with it. That's actually one of the best things about Max - you can change your patch while it's running and experiment. 

> So basically Max/MSP is a visual programming environment, with a focus on sound and visuals? But you can do other applications as well. Am I correct? Then the natural question that follows is - where goes the limit? 

>>Then the natural question that follows is -

>That's a very good question. If you try to build really

>large complex applications you are going to hit some walls.

>Max is really great for experimenting and prototyping, and

>there is a huge amount of value in that. I'd say it's good

>for making tools and utilities and smaller applications. But

>it is probably not a good choice for large, complex 

>applications. The main issue is that it has all the power of

>a full-fledged programming environment, but it doesn't have

>any of the structure of a normal text-based language that >facilitates scalability and maintenance (does that make

>sense?). Also, it's not going to replace a command shell or

>a scripting language, because you can't run a Max "script"

>from the command line. You need to open the Max GUI

Today I am something like 1000% wiser than yesterday, re. Max. Installed the demo and are following the tutorial as we speak. Let me rephrase my questions and be more specific. It supports loadining and saving files? Would it be possible for Max for example to load an old SysEx file, chop it into pieces, change the parameters, and then rebuild it back again with a new correct calculated checksum?

Listen... when I write here, I feel like a stupid chicken. Last time I made software was... h-ll. I dunno. Fifteen years ago or something. My last effort was C - and I'd rather never go down that alley again. No offence to programmers here. I just don't enjoy it as much as the rest of my life. Max seems to be a good compromise for that. The right-left thing is probably just a matter of getting used to it.

>>Then the natural question that follows is -
>>where goes the limit?

>That's a very good question. If you try to build really
>large complex applications you are going to hit some walls.
>Max is really great for experimenting and prototyping, and
>there is a huge amount of value in that. I'd say it's good
>for making tools and utilities and smaller applications. But
>it is probably not a good choice for large, complex 
>applications. The main issue is that it has all the power of
>a full-fledged programming environment, but it doesn't have
>any of the structure of a normal text-based language that >facilitates scalability and maintenance (does that make
>sense?). Also, it's not going to replace a command shell or
>a scripting language, because you can't run a Max "script"
>from the command line. You need to open the Max GUI
>environment to do anything.

Listen... when I write here, I feel like a stupid chicken. Last time I made software was... h-ll. I dunno. Fifteen years ago or something. My last effort was C - and I'd rather never go down that alley again. No offence to programmers here. I just don't enjoy it as much as the rest of my life. Max seems to be a good compromise for that. The right-left thing is probably just a matter of getting used to it.


> Let me rephrase my questions and be more specific. It supports loadining and saving files? Would it be possible for Max for example to load an old SysEx file, chop it into pieces, change the parameters, and then rebuild it back again with a new correct calculated checksum?

If I were going to do this I would probably run some Java or maybe javascript inside Max because I find it's easier to do that kind of task in a more standard text-based language.

It's theoretically possible to do something like this in Max without writing code, but in Max 4 there is a limitation on the message length that most objects accept. So for a real world sysex file you would probably hit that limitation, and currently the workaround is to jump into javascript, java, or C. This is supposed to be corrected in Max 5. The checksum part also sounds like an overly difficult task for Max, based on my experience.

But sometimes for this kind of problem, you have to step back and ask what the goal is. Instead of processing an old SysEx file, you might find other ways to control your synthesizer more directly with Max. Just to give you an idea - I have a PodXT which is a pretty cool piece of hardware, but I hate it's interface. All these menus you need to navigate through on a small LCD screen, and you can never see all the parameters you want on the screen at one time. I ended up making my own interface to the device in Max, and then built new presets for it in Max. I didn't really care about getting my old presets into Max because I was having so much fun with the new interface that I didn't care.

> Last time I made software was... h-ll. I dunno. Fifteen years ago or something. My last effort was C - and I'd rather never go down that alley again.

I understand. C is not an easy language to program in. Max has other options though, so maybe you would find javascript or even Java more appealing. If text programming really just makes your head hurt, there is still plenty you can do without writing a line of code, but some of the ideas you dream up are probably going to be a bit unrealistic.

Max can be pretty addicting, so you may find you are so busy exploring new ideas that it doesn't matter if you can accomplish every little thing you think of.

> Last time I made software was... h-ll. I dunno. Fifteen years ago or something. My last effort was C - and I'd rather never go down that alley again. 

> Would it be possible for Max for example to load an old SysEx file,

> chop it into pieces, change the parameters, and then rebuild it back

> again with a new correct calculated checksum?

Yes, of course, this was one of the issues Max was made for ca. 20 years 

You need to have the knowledge and all info about those SysEx formats 

though. Some manufacturers made it easy and others made it very 

complicated. SysEx per definition isn't standardized...

As for your pluggo install necessity, look at it as you look at flash. 

Flash files won't play either if its not installed. But imagine each 

flash animation would carry the whole application as well - I guess 

Personally I even wouldn't distribute standalones, I'd always tell 

people, get the runtime of Max/MSP/Jitter and then distribute a 

Carl Lofgren schrieb:
> Would it be possible for Max for example to load an old SysEx file,
> chop it into pieces, change the parameters, and then rebuild it back
> again with a new correct calculated checksum?

Yes, of course, this was one of the issues Max was made for ca. 20 years 
ago....

You need to have the knowledge and all info about those SysEx formats 
though. Some manufacturers made it easy and others made it very 
complicated. SysEx per definition isn't standardized...

As for your pluggo install necessity, look at it as you look at flash. 
Flash files won't play either if its not installed. But imagine each 
flash animation would carry the whole application as well - I guess 
nobody would use it...

Personally I even wouldn't distribute standalones, I'd always tell 
people, get the runtime of Max/MSP/Jitter and then distribute a 
collective...

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com

Quote: Stefan Tiedje wrote on Wed, 05 December 2007 00:48

> > Would it be possible for Max for example to load an old SysEx file,

> > chop it into pieces, change the parameters, and then rebuild it back

> > again with a new correct calculated checksum?

> Yes, of course, this was one of the issues Max was made for ca. 20 years 

Loading a file off of disk, processing its contents, and then saving back to disk using just Max objects sounds tricky. I thought Max is good at processing SysEx messages streaming over MIDI, but not so good at file processing? Am I way off?

But maybe there's no need to have Max read/write the file in most situations.

Quote: Stefan Tiedje wrote on Wed, 05 December 2007 00:48
----------------------------------------------------
> Carl Lofgren schrieb:
> > Would it be possible for Max for example to load an old SysEx file,
> > chop it into pieces, change the parameters, and then rebuild it back
> > again with a new correct calculated checksum?
>
> Yes, of course, this was one of the issues Max was made for ca. 20 years 
> ago....

Three stupid questions