Welcome to %s forums

BrainModular Users Forum

Login Register

MIDI mute/hold 2

I need help on a Patch
Post Reply
User avatar
parityflux
Member
Posts: 83
Location: Tucson, AZ USA
Contact:

Unread post by parityflux » 05 Apr 2015, 03:23

Yeah, I'm still working on this shit from last year. [life/kids/jobs]
ref thread: http://www.sensomusic.com/forums/viewtopic.php?id=4323

Image

Can you check this out for a moment? It seems like a lot of modules for a simple task. But then again, I'm not sure what constitutes a lot of modules. I just don't want to overburden the CPU on a simple task, because I worry if I replicate it a dozen times the hit will be real.

This is what this patch represents.
1) It's an audio thru for my physical synth.
2) It's a MIDI mute that will hold sustained notes if I mute it before letting go of the sustain pedal.
3) It's a thru for an external bi-directional physical MIDI controller (aside from the synth).

The #1 audio section is benign. I have no issue with it, other than it seems necessary for the rack to actually "work": audio in -> audio out

The upper MIDI filter passes only Ch 1. The lower MIDI filter only passes Ch. 16. I have it this way so my external controller always goes through. The switch controls the flow out of the Ch 1 filter. My external controller is mapped to this switch. It's a bidirectional controller, so that's why I need that CH. 16 to feed through the patch/rack, so I get a visual (LED) feedback on the external device. The 1-0 detector and the Create midi module simply send a CC 123 out when going to MUTE OFF (live) to passively release all currently playing notes. This all seems to work great.

My question is, is this overkill? (I am an optimizer) It seems like a lot of juggling for a simple concept.

In my mind I'd still love to see device-specific access in the MIDI in module, but I realize that I may not have abstracted away enough. At the same time, I feel that new users would be alienated by the rack's MIDI flow in concept without being able to peg the actual device. It is something that has always been elusive for me in Usine (and unintuitive). It doesn't mean the concept is not brilliant, which I think it probably is, it just means it is not easy to grok. Though, this point can be set aside. My main interest is in knowing if the patch at hand is obtuse (or better handled otherwise) or succinct.

Best,
-john

sephult
Member
Posts: 1144
Contact:

Unread post by sephult » 05 Apr 2015, 04:02

Image


Hi parityflux,

I smooshed my wires and took a screenshot of my latest to make you feel better.
Each of several of the subpatches are about 4-5 layers deep and about the same, then polyphony of 10.
I would not say that your patch is overkill at all!

If you are wanting to do simpler setup, script....or if you need help send me some requirements and the patch and I can script and help you.

As far as CPU usage, you have to remember that Usine really does have some wonderful thread handling.
In many cases you will see CPU usage go up but it will balance itself out. It can be very tricky understanding how Usine handles.
Trust me with the patch above, I am constantly going back and working on trying to optimize or add options to minimize CPU.
Also you have to remember there are differences in how the threads are handled as well as balanced. And on top of that you have your graphics.


Someday here I will start a wiki on design and optimization from what I know, and try to hopefully work with others to get more information and first hand experience.
A good example of trying to understand and make you feel better about how the threading and CPU works....when I started to back off on the worrying as much....
Take a several delays, you will see that the CPU does rise when you are idle and as I assume this is for buffering purposes, however if you start feeding signal the CPU reduces.
Many applications will have a Set Min of CPU, and you just see the CPU rise....in Usine you will see that cases you will actually see the CPU decrease from an idle state or another specific state.
Also sometimes where you think your CPU will be multiplied when doing sub-patches, it does necessarily mean you will have a "set" multiple resource usage as you do when you only have one polyphony. I do not have any direct experience with the coding of Hollyhock, however I just wanted to share some of my experience to help you not feel like your over-doing it.
Patch looks great for what you are doing. As I had said the only other way besides using the SDK and building specific modules would be scripting.
For MIDI I use scripting quite frequently. And as you can see I still use a lot of the Library modules, similar to how you are.

-S
"Every act of creation is first an act of destruction." -Picasso

User avatar
parityflux
Member
Posts: 83
Location: Tucson, AZ USA
Contact:

Unread post by parityflux » 05 Apr 2015, 07:14

Holy! haha. Awesome. OK I will temper myself. I just like things nice and simple and palpable. :)

User avatar
parityflux
Member
Posts: 83
Location: Tucson, AZ USA
Contact:

Unread post by parityflux » 05 Apr 2015, 07:15

I get what you are saying in terms of the CPU.
-j

sephult
Member
Posts: 1144
Contact:

Unread post by sephult » 05 Apr 2015, 08:48

I figured you did, just wanted to make you feel better. You are doing great, module wise that is awesome...lol
I can easily get out of hand, and very quickly :)

-S
"Every act of creation is first an act of destruction." -Picasso

User avatar
parityflux
Member
Posts: 83
Location: Tucson, AZ USA
Contact:

Unread post by parityflux » 05 Apr 2015, 18:42

Thanks sephult. I'm still giggling at your screenshot. Mayhem.

sephult
Member
Posts: 1144
Contact:

Unread post by sephult » 05 Apr 2015, 23:51

Well did you read my signature....I am definitely a prophet of chaos :)
"Every act of creation is first an act of destruction." -Picasso

Post Reply

Who is online

Users browsing this forum: No registered users and 19 guests