Doctor_Matt

About how long does one week of Max programming take to convert to C++ with testing and documentation? (The last two qualifiers are important.) Many thanks!

c-and-max

Well it would depend on the functionality of the original patch.

Would you have to reproduce any max externals in your c++ source?

If you are basically porting a Max patch to source and it requires

not additional reproduction of functionality, an experienced

programmer should be able to do it in half the time.

Well it would depend on the functionality of the original patch.
Would you have to reproduce any max externals in your c++ source?

If you are basically porting a Max patch to source and it requires
not additional reproduction of functionality, an experienced
programmer should be able to do it in half the time.


"About how long does one week of Max programming take to convert to C++"

strange question(when i've seen someone asking 'how long' it usually means they don't know what they're doing and are terrified about that fact and so finding ways to hesitate/procrastinate, this question being one of those ways). if you are planning on doing this, 

 would be the only one to know how long it would take you... this completely depends on 

 understanding of C++. if you're even asking a 'how long' question, it's likely it will take you forever.

plus, if you actually know c++, you'd be the only one to know how long 

get to work, it'll go much faster(even for a noob like me;).

strange question(when i've seen someone asking 'how long' it usually means they don't know what they're doing and are terrified about that fact and so finding ways to hesitate/procrastinate, this question being one of those ways). if you are planning on doing this, you would be the only one to know how long it would take you... this completely depends on your own understanding of Max and your own understanding of C++. if you're even asking a 'how long' question, it's likely it will take you forever.
plus, if you actually know c++, you'd be the only one to know how long your patch would take in 'testing'.
get to work, it'll go much faster(even for a noob like me;).


Clearing up the question for Noob, "If a Max patch is given to an experienced C++ programmer, how long would it take that programmer to convert it to C++ with testing and documentation?"

1- Assuming that we start with *no* C++ code then the complexity of the max objects used, as well as of the max patch is crucial (the functionality of each object must be reproduced in C++).

2 - This requires the C++ programmer to either be very familiar with max, or to learn max enough to understand your patch - if the patch is anything other than trivial that could take a long time.

3 - What is a week's worth of max programming? For one person that could amount to very little, another programmer may develop a complex system in that time. If they reuse old max code it could be potentially even more so.

4 - Port how much functionality? Do you want GUI / Audio I/O etc. etc. C++ for what purpose - as a library, or as an app?

5 - Who is making the patch / who is porting the patch - what are their relevant experience levels etc. etc.

Really there is no way to even start answering this question accurately without a *lot* more information (like the patch for a start).

Of course, people can offer opinions, but I wouldn't base any serious decisions on them, because even any vague predictions here could be wildly out.

Finally, why are you asking? (this is actually important to being able to give a good answer).

B - You want to check how long it *should* have taken someone who's already done it

C - you've had a time quote and want to check it.

D - you want to ask someone to do it, but before asking - want to have a ballpark.

Or maybe something else. In the first case - probably longer than you think.... In any of the others I'd say you have to ask them. If you don't trust their answer then you have to deal with that with them - any guesses here are going to be way too spurious to be of real value..

So, I'd suggest you could supply more information to allow people to answer better.

No offence intended to Anthony, but I simply don't think there's enough information here to put a figure on it.

Finally, why are you asking? (this is actually important to being able to give a good answer). 

A - you want to do it yourself
B - You want to check how long it *should* have taken someone who's already done it
C - you've had a time quote and want to check it.
D - you want to ask someone to do it, but before asking - want to have a ballpark.

"If a Max patch is given to an experienced C++ programmer, how long would it take that programmer to convert it to C++ with testing and documentation?"

you're still just asking an uninformed question and making it more and more obvious.

It's true, Anthony gave you what you needed: an answer which would encourage any newbie to get started on it and stop asking fearful questions

("half the time" is not true at all... there's just no way to know unless you, yourself know what's in the patch, namely: how to convert every max external to c++ which you will never know because cycling74 does not share the source to every object... you'll be guessing the algorithms most of the time. especially if you're asking here, anyone can tell that you are not the 'experienced' c++ programmer who will be doing all of this... you should try asking the actual programmer you're going to get to do this... the question is also uninformed, because you don't even say to what extent c++ will be used: will it be to convert a max patch to a VST or AU, or a standalone application? if a standalone application there are many other things at the operating-system level that you won't ever account fully for from the max patch alone(if just a VST or AU plugin, then yes, perhaps 'half-the-time' might actually be truer))

Seriously, think about the question you're asking before asking it. Otherwise, if you're about to ask another person who programs c++ to do this, then you're asking these questions here in a way that will lead to the unfair exploitation of that c++ programmer.

It's true, Anthony gave you what you needed: an answer which would encourage any newbie to get started on it and stop asking fearful questions
("half the time" is not true at all... there's just no way to know unless you, yourself know what's in the patch, namely: how to convert every max external to c++ which you will never know because cycling74 does not share the source to every object... you'll be guessing the algorithms most of the time. especially if you're asking here, anyone can tell that you are not the 'experienced' c++ programmer who will be doing all of this... you should try asking the actual programmer you're going to get to do this... the question is also uninformed, because you don't even say to what extent c++ will be used: will it be to convert a max patch to a VST or AU, or a standalone application? if a standalone application there are many other things at the operating-system level that you won't ever account fully for from the max patch alone(if just a VST or AU plugin, then yes, perhaps 'half-the-time' might actually be truer))

Seriously, think about the question you're asking before asking it. Otherwise, if you're about to ask another person who programs c++ to do this, then you're asking these questions here in a way that will lead to the unfair exploitation of that c++ programmer.


It would also depend on how much functionality you want in the patch, and what kind of functions. Translating things like select, uzi, counter, gate, etc... would be pretty straightforward, *assuming* you can determine all the variables you're working with. If patch cords represent values, and many times variables, it could take awhile to determine how many local and global ones you want, and to keep their scopes correct. But it should be possible.

That said, if you want to have high levels of functionality with certain processes like video or signal processing, I suppose depending on how rich the libraries already are (meaning the less you have to code from scratch) the easier it could potentially get to program. Again, at what point are you not really "coding" but simply doing a "pastiche" of pre-written chunks? Which is *totally fine* and leads to lots of progress overall, but can also lead to not understanding some essential things under the hood... it's often a balancing act between how much you need to know to get something working versus how much you think you *should* know in a general sense, for understanding and for assistance in future projects. So, for example, if you're being well-paid to program and to build your knowledge (or if you're in school for it) that's a golden opportunity to take your time and explore... other times you need to just get that thing done, for whatever reason: clients, time, money, burnout, etc. So those are pretty different scenarios.

So if the patch is relatively simple, it should be fairly straightforward. Just looking at some objects and connections and talking through them in pseudocode has been helpful to me---to understand more about Max as well as code itself. And the idea of translating back and forth is intriguing. But if you want to program all the functions available in (say) jit.qt.movie, well... have you clicked that inlet recently? :)

So if the patch is relatively simple, it should be fairly straightforward. Just looking at some objects and connections and talking through them in pseudocode has been helpful to me---to understand more about Max as well as code itself. And the idea of translating back and forth is intriguing. But if you want to program all the functions available in (say) jit.qt.movie, well... have you clicked that inlet recently?  :)


I don't understand what the confusion is. I think the question is

pretty straight forward. Max is a programming language, c++ is a

programming language. Assuming you did not have to reproduce any

functional externals like FFT~, groove~, etc. it should take you

have the time to port code from one language to another. Most Max

externals are pretty simple and can easily be ported to c++.

I think it is a valid question because sometimes it is just faster

to code something up than to build it in Max.

I don't understand what the confusion is. I think the question is
pretty straight forward. Max is a programming language, c++ is a
programming language. Assuming you did not have to reproduce any
functional externals like FFT~, groove~, etc. it should take you
have the time to port code from one language to another. Most Max
externals are pretty simple and can easily be ported to c++. 

I think it is a valid question because sometimes it is just faster
to code something up than to build it in Max.


First question - is the C code going to be a Max external, or a stand-alone program? If you're going to make a Max external, things are a little easier. With proper code factoring, thing that are done well in Max can stay in Max, and things which need to be more efficient can be done in C.

If you're coding it for another platform, in another language such as C/C++, you have to deal with a bunch of things that just come for free in Max. For example, consider the scheduler, or MIDI / audio I/O. These represent a bunch of work behind the scenes that may not be obvious when looking at a patch.

I've been using Max to prototype some things that I eventually port to C on dedicated hardware without an OS. When I do this I'm very cognizant of what is available in C and stdlib, and code in max accordingly. This means avoiding 

 objects, and programming Max at a fairly low level. The discipline involved requires an intimate knowledge of the target platforms capabilities, and programming in Max accordingly.

I've been using Max to prototype some things that I eventually port to C on dedicated hardware without an OS. When I do this I'm very cognizant of what is available in C and stdlib, and code in max accordingly. This means avoiding many objects, and programming Max at a fairly low level. The discipline involved requires an intimate knowledge of the target platforms capabilities, and programming in Max accordingly.


yes, just the scheduler alone is a huge thing to consider(so is I/O of any kind).

"Assuming you did not have to reproduce any

functional externals like FFT~, groove~..."

i can't assume that. there's so many 'functional externals' that may pervade any patch...

but you're right, it is a valid question... more valid if we all could actually see the 'Max programming' in question.

chris muir wrote:
"consider the scheduler..."
yes, just the scheduler alone is a huge thing to consider(so is I/O of any kind).

anthony wrote:
"Assuming you did not have to reproduce any
functional externals like FFT~, groove~..."
i can't assume that. there's so many 'functional externals' that may pervade any patch...

but you're right, it is a valid question... more valid if we all could actually see the 'Max programming' in question.


The question is far to general to be able to provide any meaningful answer to. Add one MSP or Jitter object to the patch, and you suddenly have to develop support for audio and video in your program. That's no minor task.

That being said, the papers on the Jamoma DSP and Jamoma AudioGraph frameworks by Tim Place, myself and Nils Peters presented at ICMC 2010 and the upcoming DAFx conferences might be of interest if you want to develop audio code and graphs ("patches") that might be used in Max as well as other environments. Mind you that the AudioGraph framework is still in a relatively early stage of development, we only started working on it 2 years ago...

I would turn the question upside down. I am on a project which used a program written in C or C++. It took them two years to develop. It took me 5 days to do almost the same in Max...;-)

Max is often used as rapid prototyping. But if a Max patch works, there is not really a need to convert it, unless you want to run it on some rare processors. In this case I would switch to Pd though...;-)

Of course, if you plan to create the new commercial competition to ProTools or Live, you'd better hire (a lot of) professional coders and ask them...

The documentation part is not dependent on the programming language btw. unless you mean comments in the code. Max is almost self documenting and probably needs less comments. But typing a comment itself takes usually the same time...

"The documentation part is not dependent on the programming language btw."

i'd say the same is true of the 'testing' part to some extent(not so much the 'fixes' but definitely the 'testing' part, in fact, testing is often done better by non-developers/non-programmers imho).

"I am on a project which used a program written in C or C++. It took them two years to develop. It took me 5 days to do almost the same in Max...;-)"

Now that is something I can indeed believe easily without question or need for any further details.

stefan wrote:
"The documentation part is not dependent on the programming language btw."
yes, true!
i'd say the same is true of the 'testing' part to some extent(not so much the  'fixes' but definitely the 'testing' part, in fact, testing is often done better by non-developers/non-programmers imho).

"I am on a project which used a program written in C or C++. It took them two years to develop. It took me 5 days to do almost the same in Max...;-)"
Now that is something I can indeed believe easily without question or need for any further details.


Is there an app that would translate, i.e., make the MAX patch portable to an orphan machine NOT running MAX?

So a better Q:
Is there an app that would translate, i.e., make the MAX patch portable to an orphan machine NOT running MAX?


I'm missing something here. Why can't you just build a max standalone that just uses the max runtime system which can be freely distributed?

C++ and Max