Extreme CPU useage

[pljones]

Do you mean to say "MUX" rather than "MPA" (or have I missed a feature change, being out of the loop as I am right now)?

As you say, Jo, it means the user is responsible for load balancing... Well, to a degree. Can a rack not be reworked as a specialised MPA? That way, each rack would get its own thread. (I can't see the point of each VST in a rack getting its own thread -- it's a single, sequential signal path, after all. And if you do want that level of parallelism, stick an MPA in!)

Pros: both powerful and simple, the true Tao of MULAB
Cons: only addresses the audio/real-time/"process()" path, not the GUI; is it really as easy as it sounds in terms of architecture?

[liquidsound]

Thinking loud about multicore support: Last night i had this idea:

Maybe each MU.LAB Session could have more than 1 MPA. Each MPA runs in a separate audio thread i.e. a separate core, when available.

Jo....
Wouldn't it be better to keep just one MPA and use the usual graphical element for each Core for routing so to keep everything in one window? Mulab = Simplicity....

BTW Awesome idea!

[MuTools]

Do you mean to say "MUX" rather than "MPA" (or have I missed a feature change, being out of the loop as I am right now)?

The MPA (Modular Plugin Area) is the modular studio room of a session. (maybe Modular Studio Room is a nice term too, it sounds more concrete)

As you say, Jo, it means the user is responsible for load balancing... Well, to a degree. Can a rack not be reworked as a specialised MPA? That way, each rack would get its own thread. (I can't see the point of each VST in a rack getting its own thread -- it's a single, sequential signal path, after all. And if you do want that level of parallelism, stick an MPA in!)

That's certainly a very good idea!
I'll think about it more.

Pros: both powerful and simple, the true Tao of MULAB
Cons: only addresses the audio/real-time/"process()" path, not the GUI; is it really as easy as it sounds in terms of architecture?

MU.LAB's GUI is single-threaded and there are no plans to change that. It's about multi-threading the audio processing. I think there are 2 main aspects:

1) How to realize it within the MU.LAB architecture
2) How to start/pause the extra audio threads in an efficient way

The first point is a matter of finding the best signal path 'atoms' that can be processed without being dependent on other signals. As you said, racks may indeed be such atomic items.

About the second point: That's where i still need to do most research. I guess it's a matter of launching NumCores-1 extra audio threads that have the same priority level as the main audio thread, and that are wakened when the main audio thread asks for processing, and that are sleeped when the audio processing is done for that cycle. Once that's realized in an efficient way, these audio threads can effectively process the signal atoms.

I think it's important that the audio threads do not have to wait for eachother's results as that will seriously decrease the multi-core advantage.

[MuTools]

Wouldn't it be better to keep just one MPA and use the usual graphical element for each Core for routing so to keep everything in one window? Mulab = Simplicity....

Yes, easiness is sacred!

Not sure what you mean with "use the usual graphical element for each Core for routing" though.

Do you mean something like: 1 MPA window with multiple 'tabs' so to switch to the different 'Cores'?

[liquidsound]

Pljones = each rack would get its own thread. No bad at all!

What I mean with the MPA is instead of "Two Rooms", "One Room with Two/Three Doors" (Cores) etc. represented by your usual PlugIn Icon as in the Audio Output, so all we need to do is to connect the elements to the desired Core, or maybe each PlugIn could be switched to the appropriate core by a context menu with a visual clue like Color or anything else. This would avoid multiple windows or Tabs and the management would be very quick. Trial and error by just a click of a mouse without switching and dragging elements between windows.
I hope I am grasping what you are trying to implement, or maybe I am off completely.

On a different note:
Is it possible to add a divider in the Sequence Editor like the one between the Note and Value editor in order to see the Composer, giving the ability to just choose a sequencer to work with, in a more rapid fashion?
It allows the editing on the fly while following the song. Very fluid. You click on a sequencer and it appears in the Note editor without closing/opening back and forth.

[MuTools]

What I mean with the MPA is instead of "Two Rooms", "One Room with Two/Three Doors" (Cores) etc. represented by your usual PlugIn Icon as in the Audio Output, so all we need to do is to connect the elements to the desired Core, or maybe each PlugIn could be switched to the appropriate core by a context menu with a visual clue like Color or anything else. This would avoid multiple windows or Tabs and the management would be very quick. Trial and error by just a click of a mouse without switching and dragging elements between windows.
I hope I am grasping what you are trying to implement, or maybe I am off completely.

No, it won't be a solution.

Essential thing is to find/make a couple (as many as there are cores) of plugin chains that are 100% independent from eachother. Hope you know what i mean. Else i could post a picture explaining it.

Is it possible to add a divider in the Sequence Editor like the one between the Note and Value editor in order to see the Composer, giving the ability to just choose a sequencer to work with, in a more rapid fashion?
It allows the editing on the fly while following the song. Very fluid. You click on a sequencer and it appears in the Note editor without closing/opening back and forth.

Yes it should be possible.

I'll add a note on the whishlist about it, be it a preference whether the sequence editor should be used in a docked or in a floating window, almost similar as the choice you have now with the Rack Desk.

If used in floating window mode, it should also be possible to open several sequence editors at the same time, which could be an answer to the request to edit/see more sequences at the same time, so that edits can be matched.

So it is added on the whishlist

[liquidsound]

I think we are on the same page regarding the Independent PlugIn but a picture = 1000 words or...Posts

Both solution to the Sequencer Editor are great, it depends how large is the monitor though. The Floating with multiple Sequencers open at the same time requires a larger monitor while the other with the Split divider is very useful on laptops.

[MuTools]

Order of processing:

1) Drumz
2) Bass
3) KraftLine
4) Limiter
5) Echo
6) Master
7) Output

The system could process these 'atomic signal paths' at the same time without any dependency:

1) Drumz
2) Bass -> Limiter
3) KraftLine -> Echo

But Master cannot be processed before these 3 atoms are fully processed.

So when doing things multi-threaded, there will be a thread that has to wait for another thread. It would be nice it that could be avoided. But as said, i'm not yet an expert at this, need to do more R&D on it, at later time.

I'm not sure how to let wait thread X for thread Y in a very efficient way, so that almost no cpu is wasted by the thread management itself, i.e. i would like to minimize the multi-threading overhead, and maximize the multi-threading benefits.

This question must be solved on both OSX as on Windows.

[pljones]

Jo,

If you try to multi-thread at the MPA plugin level, you're going to have to manage graph dependencies, as you say. There's no point allocating "Master", in your example, a thread on a core if its dependencies haven't been met for that process cycle. However -- it's going to need a thread from your thread pool (which is the usual way of managing it - rather than creating and destroying threads constantly) immediately the dependencies are met. And managing graph dependencies means you've got to handle possible loops in the graph very carefully. I'll leave you to the intensive R&D as there's such a wide range of approaches and I don't have enough experience at the level required to comment (i.e. I know some theory but nothing practical in terms of real-time performance).

Maybe each MU.LAB Session could have more than 1 MPA. Each MPA runs in a separate audio thread i.e. a separate core, when available.

I'm simply not clear on how this would work or provide a benefit. At the moment, it's fairly easy to understand that a composition (--it's per Session? I didn't realise that!--) has an MPA and parts/tracks (--in various compositions?--) can route into the various exposed inputs. If you start having multiple MPAs, that's yet another list of stuff the user has to name and keep track of. At which point, I think they'd prefer to stick to using a MUX (which is pretty much the same as the MPA, really) for each small piece and use a single MPA to organise the pieces. Multi-processing at the MUX (or whole Rack) level does give you that atom, as you say.

[TheGuysanIdiot]

Well I am not a programmer so unfortunately can not tell anyone how to code for multicore computers.

All the PCs I normally use for music creating are single core PCs.

Well during the Christmas break I may go on another of my virtual motorcycle journeys.

It is not likely that we will see future single CPU PCs. The multi CPUs are used to decrease heat due to increasingly high CPU speeds. So it seems that multi CPUs are here to stay for a while. So I guess software needs to be rewritten to utilise this technology.

Again a personal journey for me. But others may find it useful.

OK I now have in my possession a dual core PC, one of my business PCs usually used for office stuff.

I am keen to find out how much better a dual core PC will be running a multicore aware audio program.

As it happens Reaper already has multicore type coding. What I will do is see how this program performs on the multicore PC and compare it to my main single CPU music PC.

OK this will help me see into the future and give me a rough indication what a multicore MULAB may feel like.

I will only do this stuff if I get bored over the Christmas break. I personally have always wondered what is better. A very fast single CPU PC against a dual core of less GHz.

OZ

[MuTools]

However -- it's going to need a thread from your thread pool (which is the usual way of managing it - rather than creating and destroying threads constantly) immediately the dependencies are met.

But even when working with a thread pool, how can we immediately start/pause threads? It's especially the word 'immediately' which contains the essence of the problem. (immediately not being 0 of course as that doesn't exist in nature, but being very very sharp timing, say a couple of microsecs or so)

Maybe each MU.LAB Session could have more than 1 MPA. Each MPA runs in a separate audio thread i.e. a separate core, when available.

I'm simply not clear on how this would work or provide a benefit. At the moment, it's fairly easy to understand that a composition (--it's per Session? I didn't realise that!--) has an MPA and parts/tracks (--in various compositions?--) can route into the various exposed inputs. If you start having multiple MPAs, that's yet another list of stuff the user has to name and keep track of.[/quote]

Indeed, i agree that's a real disadvantage of that idea.

At which point, I think they'd prefer to stick to using a MUX (which is pretty much the same as the MPA, really) for each small piece and use a single MPA to organise the pieces. Multi-processing at the MUX (or whole Rack) level does give you that atom, as you say.

Will think about it more, at proper time.

Thanks for sharing your thoughts. It's an interesting and important topic.

[MuTools]

It is not likely that we will see future single CPU PCs. The multi CPUs are used to decrease heat due to increasingly high CPU speeds. So it seems that multi CPUs are here to stay for a while. So I guess software needs to be rewritten to utilise this technology.

Yes, i also believe multi-core/multi-threading is key to more processing power. It's a logical/natural/efficient way of increasing power. Just like they used to use multiple horses to drag a heavy thing.

As it happens Reaper already has multicore type coding. What I will do is see how this program performs on the multicore PC and compare it to my main single CPU music PC.

Curious for your comparison results.

I will only do this stuff if I get bored over the Christmas break. I personally have always wondered what is better. A very fast single CPU PC against a dual core of less GHz.

I also wondered about that. But it will depend on the software i guess.