Forums > MaxMSP

feature possibility? encapsulating msp external that uses DSP board

June 26, 2006 | 1:18 pm

Well, ok, I’ve been musing of an object similar to poly~ that does its processing on a hardware dsp board, maybe pci, maybe rackmount. I’ve sort of dubbed this external "pci_poly~" in my mind, albeit this is just a muse of mine and I have not the skills to see this happen.

But is it possible? We have the SDK, we have platforms like SCOPE and so forth that use DSP chips to do their processing as inspiration… There seems to be a plethora of boards for sale around and about on the old info highway… I think it would be really cool to have an encapsulation to specify which signal goes to the board, or a set of externals that just use the board exclusively… [if i remember right, the poly~ object is the *only* msp external that seperates the signal network]…

Albeit, I’m sure it presents a billion problems. MSP can be a bit hungry though, sometimes its not good for the Max side of things when it gets hairy on the MSP side. I like being able to do things just within MSP within extending to hardware or remote computers, but even on my more than humble processor it doesn’t seem to suffice sometimes when it REALLY matters…… [trying to record something professional]

Just a thought, anyone thought of anything like this yet? Let’s pretend cost isn’t an issue.. I feel like someone’s going to say "ppff!!!! you know how much that would cost?!?!"

yeah,
binez0r


June 26, 2006 | 1:31 pm

its called kyma.

http://www.symbolicsound.com

5 figures for a good one.


June 26, 2006 | 1:40 pm

bleh!

i already know about kyma. In fact I’ve talked with Carla [owner] on the phone a couple times. I’ll be purchasing a system in the future. I already have DSP cards. Thanks for your all in one solution to something partially related :/

Hence, I was just proposing the idea of a pci based DSP card that used a msp external as a gateway to its processors.

God! I hate when people post stuff like that! guess you were just trying to be helpful. Oh well.


June 26, 2006 | 2:14 pm

oof. email before coffee = bad posts by me…

i think there were some projects kinda like what you mentioned, using
PD a few years back. it would be in the procedings on the NIME
conference 2003. in the poster or demonstration sections.

> Hence, I was just proposing the idea of a pci based DSP card that
> used a msp external as a gateway to its processors.


June 26, 2006 | 2:52 pm

if you do it on the gpu, i will build an altar for you with an ivory and gold statue : )
it’s possible, check out bionic fx and i think some people are working on it in japan for a vst and maybe max version.

one of the current dsp cards, forgot the name, popular and cheap is a modified gp card.


June 26, 2006 | 3:55 pm

well yes that would be cool, I know all about bionicFX.. I also know about scope, uad, powercore, kyma, bleh and blah… etc etc. I just want something hardware DSP thats linked directly to various msp functions or an encapsulation such as poly~ [in external form]

phew,

binez0r


June 26, 2006 | 8:37 pm

so you want a poly~ which translates native code
to assembler on the fly?

let me know when you have altiverb~ or gverb~
running on the powercore … or my custom abstractions.

110 (who thinks that is what plug-in interfaces are for) :)


June 26, 2006 | 9:53 pm

binezOr

Oh yeah, I think I’ve done something like this before, but I’m not going to tell you about it. I think it’s better that way, don’t you? You know, people need to figure it out for themselves, right?

8-)

H


June 26, 2006 | 10:23 pm

pwn3d!

v a d e //

http://www.vade.info
abstrakt.vade.info


June 26, 2006 | 10:27 pm

It’s been done before, though that was back in ISPW days on the NeXT,
IIRC. Given the time period, I think it was probably definitely
faster, but at ca. $10,000 for the card…

Gotta love commodity hardware.

Peter McCulloch


June 27, 2006 | 6:27 am

Hi,

I think it has been done also during the first 90′s for Opcode Max.

I remember that in the package (I’m talking about the big manual with
the binders) was included a sheet of paper with the info about the dsp
boards.

All the best

Alessandro Fogar


June 28, 2006 | 5:53 am

Yeah, I was familiar that was the case. I also remember something like max running on 4 seperate processors or similar for a variety of different functions. Someone correct me :)

I don’t mean that the dsp boards should be the core of how msp should be configured. of course doing it in software has many benefits and the amount of maxers using laptops is a testament to that.

I think it would be a nice 3rd party unsupported expansion option is all I mean, being i think we have all the tools to bring it together. i’m pretty content using a pluggo matrix over ethernet as well as hardware with Max.

I don’t wish to be done with outboard gear.. Just would lilke to expand the possibilities of working strictly in software. I mean, what if we had seperate computations within a single computer for the various signal formats. max on cpu, audio on pci dsp, jitter on [daisy chained?] pci express slots. so many tradeoffs have to be made, well I know most of you already know that 8-)

binez0r


June 28, 2006 | 10:40 am

binez0r wrote:
> well yes that would be cool, I know all about bionicFX.. I also know
> about scope, uad, powercore, kyma, bleh and blah… etc etc. I just
> want something DSP thats linked directly to various msp functions or
> an encapsulation such as poly~

If you’d have externals which run on the DSP, you could still use the
normal poly~ to do all voice allocation. There are vst~s which run on
the TC-core external DSP, you could easily access them within a poly~.
Unfortunately those vsts are not "basic" enough and would probably
create lots of overhead…

But if you are into DSP and c programming, you should be able to create
some basic building blocks which you feed from within a Max poly~…

Stefan


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


June 28, 2006 | 11:49 am

thats is the right idea (=closest to what has been asked for)
but not unproblematic … a powercore plug-in can not be
loaded into a turned-off poly.
after the poly has been turned on the user will not know,
when the plug-in has finished loading as he has the edit
window closed (he has doesnt he)
the idea to run custom DSP on a PCI card is tempting but
someone needs to write us specific externals for that.


June 28, 2006 | 4:02 pm

how ironic, I made jokes about the tdm~ object yesterday.

I’ve tried writing arguments against this idea for an hour… I
guess that means I like it. still it seems cumbersome and would need
a fark-ton of engineering. you couldn’t just port the code.
-matt


June 28, 2006 | 9:27 pm

Roman Thilenius wrote:
> thats is the right idea (=closest to what has been asked for)
> but not unproblematic … a powercore plug-in can not be
> loaded into a turned-off poly.

Why not? It does work with other VST’s why shouldn’t it work with a
Powercore VST?

> the idea to run custom DSP on a PCI card is tempting but
> someone needs to write us specific externals for that.

Yes…

Stefan


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


June 29, 2006 | 2:05 am

The powercore only allows its own vsts. Same with Uad-1/Scope, etc. You could probably turn it off via poly~ with the disable/bypass message which turns off processing [i think, untested]…

"bypass The word bypass, followed by a non-zero argument, stops any furtherprocessing by the currently loaded plug-in and copies the object’s signal input to its signal output. bypass 0 enables processing for the plug-in."

however, its not that I just want to use high level vsts. I mean, just for max stuff, modular you know, like kyma but with some msp externals. maybe even an external that took an msp object as an argument and created a clone of its i/o code within the external… or a library that just ran in and out through the cards. pci.lib or what have you.


June 29, 2006 | 2:26 am

Ok. Do you really know how little processing you can actually do on an external DSP card like the power core? Most of these are based on a Motorola 56XXX style DSP with 24 bit int processing. By the time you do a float to int convert and the return you may be at a net loss of cycles. Then all the ranging and overflow checking you need to do to keep things within bounds, it is hardly worth it. Yes there are farm cards, but they still they pale by comparison to what you can pull off in a Pentium or a G5 by an order of magnitude.

I’ve moved the OMX Dynamics Processors from general purpose CPUs to all styles of DSPs and there is very little to get excited about. Take advantage of any style of multicore / multi CPU processing and you will be much better off and with a lot less heartache than dealing with slow clock, finicky DSPs. Unless you want to have a hardware lock on a market (Digi, TC, UA), need to do matrix processing (GPU) or make a $50 consumer audio product stay with the host – trust me.

Keith

binez0r wrote:

The powercore only allows its own vsts. Same with Uad-1/Scope, etc. You could probably turn it off via poly~ with the disable message which turns off processing.

"bypass The word bypass, followed by a non-zero argument, stops any furtherprocessing by the currently loaded plug-in and copies the object’s signal input to its signal output. bypass 0 enables processing for the plug-in."

however, its not that I just want to use high level vsts. I mean, just for max stuff, modular you know, like kyma but with some msp externals. maybe even an external that took an msp object as an argument and created a clone of its i/o code within the external… or a library that just ran in and out through the cards. pci.lib or what have you.

Keith McMillen
BEAM Foundation
http://www.beamfoundation.org/
510.502.5310


June 29, 2006 | 6:55 am

Well what I find is that no matter how time I spend optimizing things, the type of signals i tend to manipulate generally have a tendancy of overloading my less than modest system.. I wouldn’t mind a dedicated audio math processor to take the load off sometimes.

I currently have a modular environment setup on my 2nd pc linked to Cubase via plugsync~ (hehe). It can get pretty hairy in max especially when I need to record. If I had audio functions seperate from the same processor [dual core, quad core, whatever] I am almost certain I would some improvements.

A fully expanded Creamware scope system is well under $3000 these days and with 42 150 Mhz Sharc chips on 3 boards [and amazing sound quality] and seems to pull quite a lot of pure number crunching power. I read that people were building setups with 10-15 relatively large softsynths and the such.

Muse’s receptor is much more capable of processing its audio being as its a dedicated OS and such with all the junk stripped out.

Add video to the mix and the whole package just starts to suck. Framerates drop, countless tradeoffs are made [common topic].. Hell I know its realtime. I don’t think finnicky is the right word. Kyma uses the same setup and the specs on a fully expanded kyma system are pretty damn impressive, something like 2000 partial additive synthesis? No CPU overhead? Which means Max can interact with a variety of other things as well, such as video devices, lighting, networked computers without the crap you get from the scheduler.

Anyways, well., one can dream of solutions [besides bouncing every 5 minutes]. For now the only viable option for the way i work is hardware synths and effects units. I have never been able to use MSP for anything other than improv [a-chaos!] and quick prototypes/pedagogal purposes.


June 29, 2006 | 7:31 am

also, I think Digi, TC, UA should be left out of it. I know i brought up the powercore and such. Its not a good example. I mean, what about the lemur, it works in Max.. it costs a ton to make… We don’t have a dedicated signal processor for max, just a general cpu running heavy operating systems and such sample by sample dsp calculations seem to me to be better than buffer based operations on general computers.

And what of the Sharc 200mhz chip? on paper it seems pretty fast to me. I can’t imagine 10 of those on a dedicated irq with a pci-express bus wouldn’t offer at least some relief, and plus its within the computer, so of course theres a tradeoff. i am definetly factoring in the ease of maintaining one operating system on one computer as opposed to what i do now, which is jump back and forth between 2 computers constantly. [cubase+rewire collective on 1, open Max on the 2nd]…

binez0r


June 29, 2006 | 7:40 am

I mean, max is also about [hehe ramble ramble] patching together various sources through various protocols. Whether that be OSC or a serial port, a gamepad or a sensor, max has a lot of flexibilty with incorporating devices into every available port in oh so many different ways. The one thing I don’t see max using is a pci bus :) for hack and patch fun time.

i’ve built so much insane stuff with max. I am working on an editor for my yamaha tx816 thats really bringing the beast to the surface, as well as my jd990, yamaha fs1r, hardSID :D etc… max can do it all. Where I mean, the powercore is just 14 plugins.. pretty boring if you ask me, yet I read reviews that people get quite a nice boost in headroom when using these pci based solutions.

I’ve been talking with the folks at creamware. Albeit biased, they seem to think DSP chips are far better for processing audio than general CPU chips. Well, can’t blame them.


June 29, 2006 | 9:23 am

On 26-Jun-2006, at 15:18, binez0r wrote:
> Albeit, I’m sure it presents a billion problems.

No, it presents one problem.

A poly~ has absolutely no knowledge of what’s going on inside the
individual external objects it uses. A poly~ doesn’t even know what’s
going on inside a +~.

How can it? A poly~ can contain any of the hundreds and hundreds of
objects available for MSP, many written outside the sacred halls of
Cycling ’74.

You have got to understand the fundamental principle that each object
in Max/MSP/Jitter is a black box unto itself. In order to move *any*
processing onto a DSP chip, each and every object would also need to
be ported to that same DSP chip on a one-by-one basis.

So it would not be enough to have a pci_poly~, you would need
everything from a pci_abs~ to a pci~_zigzag~ plus everything in between.

> Let’s pretend cost isn’t an issue.

If you want to dream, then OK, pretend cost isn’t an issue. If you
really want this to happen, cost isn’t an issue, it’s the only issue
that matters. That is, cost/benefit is the issue.

I won’t repeat Keith McMillen’s excellent points about minimal
benefit. He can also judge better than I just how expensive DSP
development is. Nobody except the good people hosting this maillist/
forum can judge how much PCI-capability would add to the price tag of
Max/MSP. But how much would you be prepared to pay?

Whatever your answer, the money would be better invested in a faster
computer.

Sorry for being a wet blanket, and w/apols to Vince and Red,

— Peter

————– http://www.bek.no/~pcastine/Litter/ ————-
Peter Castine +—> Litter Power & Litter Bundle for Jitter
Heavy-Duty Mathematics for Everyday Use
iCE: Sequencing, Recording &
Interface Building for |home | chez nous|
Max/MSP Extremely cool |bei uns | i nostri|
http://www.dspaudio.com/ http://www.castine.de


June 29, 2006 | 1:04 pm

No, thats great Peter. Those are the kind of answers that help me understand the scope of things. I’m very happy with that response 8) … anyways, I think then if thats the case then there probably isn’t any incentive to make a move.

Extra computers are a pain though! Eek! :P

Thanks all for the response,

binez0r


June 30, 2006 | 8:49 am

binez0r wrote:
> No, thats great Peter. Those are the kind of answers that help me
> understand the scope of things. I’m very happy with that response
> 8) … anyways, I think then if thats the case then there probably
> isn’t any incentive to make a move.

Also consider the time of developement and the faster increase of speed
for general purpose CPU’s compared to DSP chips. By the time you are
ready to do the first tests, the normal CPU has the same power…

I hope Kyma will survive into the non DSP world on the long run, as its
a wonderfull language. There are actually links between Max and Kyma. At
the moment its the best bet if you need high quality power and
flexibility (and if you can afford it). I’d recommend it, most of the
work is done there already…

Stefan


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


June 30, 2006 | 10:08 am

Yes, I already have plans to add a kyma setup to my hardware+MAX rig =D It’s kind of a long term goal though, and, I figure why not delve as deep as I can into the max and midi world of controlling my gear in insane ways before adding another ‘language’ to the mix. A few months back I was learning CSound and even though I really enjoyed what I managed to gather I realized that there was so much to learn about max/msp still that it seemed kind of futile..

Anyways, I’ve read the kyma X exposted book and spoken on the phone with a few kyma owners and Carla. Back in January I was like minutes away from buying a capybara and such… Soon soon, all in good time. I’ve also read about the flame? external which does something with Max and the Capybara. I would love to know more about all this.

The kyma users I spoke with all seemed to dislike max very much though and approved more of supercollider and csound. Dunno why that is, but the 3 kyma users I talked to whom I told I used max really thought it rather vile! maybe an over exaggeration, but 1 person said to use supercollider instead and 2 for csound!! [ guess they're missing out, huh ;p ]

Anyways, yeah, kyma is timeless. My plans for the future are to make some OSC enabled pluggos for use with a muse receptor, an interface for the creamware scope dsp platform, and a lot of fine tuning with my hardware synth and vst environment, so, yeah… lots to do!!

[ramble ramble]

binez0r


June 30, 2006 | 10:41 am

hi

it seems quite "strange" to me. Or maybe "immature"…

Of course you do what you want , but when comparing the costs and the
weight (this is if you play live, and have to carry your equipement),
if you need more power , why not use 2 laptops and connect them (OSC
+ digital audio)???Csound makes a lot of sense, since you can use it
_inside_ max (with csound~) Supercollider _was_ a superb program but
i have the feeling it did not evolve that much in recent years…

Kyma should be fine – but it is expensive and bulky too…. and
mixing languages will not make you work faster: I am trying to
incorporate Reaktor into my patches (as plug-ins inside max) and i
see for all the little synths/filters i build in Reaktor, how faster
i could do it in max – just because i know max much better!!!

anyhow, of course you do what you want – but i see how, in a few
years, i was checking CPU all the time when building patches, when
now i can add a fft at the last minute before a concert without
worrying too much

best

kasper


Kasper T. Toeplitz
noise, composition, bass, computer

http://www.sleazeArt.com


June 30, 2006 | 12:37 pm

Quote: Kasper T Toeplitz wrote on Fri, 30 June 2006 03:41
—————————————————-

> Kyma should be fine – but it is expensive and bulky too…. and
> mixing languages will not make you work faster: I am trying to
> incorporate Reaktor into my patches (as plug-ins inside max) and i
> see for all the little synths/filters i build in Reaktor, how faster
> i could do it in max – just because i know max much better!!!
>

I feel the same way, hence why I would like to do everything in max, on one computer and not add anything else to the mix. At the start of this post kyma was brought up and that wasn’t the solution I think I was looking for…

I was using Bidule and Reaktor with OSC just because they supported it. No point really. Just stay within Max. Which is what I was getting at… max is the ultimate mantlepiece and should be treated accordingly. I use other apps, but they all revolve around Max these days. Cubase I use just as a piano roll and as a host for OSC enabled pluggo plugins which are controlled from a seperate computer [!]

Yet at this point I understand [well have always without really] the trade offs. I mean, its always seemed like an over the top unnecessary extension. I just am not overly thrilled with the results I get using huge networks of audio on 1 or more computers. And, the way I feel about increasing in processor performace over the next years I was trying to think of ways to keep pushing performance barriers.

I know its silly to complain. I really don’t want to. Max for me is the most amazing application i’ve ever used and I use it daily as much as possible. Its extended to so many facets of my studio as well as computing/art work/etc I don’t really want to learn any other language. Yet, most of us know that the BIGGER your patch gets the more compromises you have to make….

I see things like RTAS>VST wrappers and pci cards that use the Steinberg VST SDK to pipe in and out audio buffers as if they were localized plugins and I think to myself… why can’t we maxers have the same sort of computational extensibilty options *within* the language… right now I feel max works in reverse, it allows extensibility with external devices.. which is pretty amazing.

I feel like I’m pushing the limit of my hardware and software at times and, the syphoning of power that comes from bouncing down audio and picking up the pieces can be exhausting [poor me]. Ode to dreaming… oh and =P


June 30, 2006 | 1:05 pm

>
>I see things like RTAS>VST wrappers

as far as i know nothing like this exists – digi would allow it
(vst->rtas does exist, sure)

best

kasper

Kasper T. Toeplitz
noise, composition, bass, computer

http://www.sleazeArt.com


June 30, 2006 | 1:21 pm

sorry, yeah, thats what i meant 8)
the point remains the same though, there is a bridge there.


July 5, 2006 | 4:36 pm

binez0r wrote:
> The kyma users I spoke with all seemed to dislike max very much
> though and approved more of supercollider and csound. Dunno why that
> is, but the 3 kyma users I talked to whom I told I used max really
> thought it rather vile! maybe an over exaggeration, but 1 person said
> to use supercollider instead and 2 for csound!! [ guess they're
> missing out, huh ;p ]

We do have a Kyma here in the studio, and I think the preferences are
much connected to the personal history. I didn’t have the time to test
the said flame external yet, but hopefully I’ll give it a try soon, also
the drivers which are available now.

For the other languages I’d guess supercollider and kyma are cousins, as
they are both smalltalk derivates as far as I know…
But supercollider and Max are also cousins, because the first version of
supercollider started as Max external called Pyrite…

> Anyways, yeah, kyma is timeless. My plans for the future are to make
> some OSC enabled pluggos for use with a muse receptor, an interface
> for the creamware scope dsp platform, and a lot of fine tuning with
> my hardware synth and vst environment, so, yeah… lots to do!!

I guess i’d concentrate on one of those external hardware concepts,
decide which one fits best and then stick with it. I think Kyma is to
Scope what is Max to Reaktor. Kyma and Max are more universal than those
"programmable effects devices". Kyma and Max are real programming
languages… (I havent’t looked at Scope for a long time though)

Stefan


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


Viewing 30 posts - 1 through 30 (of 30 total)