I'm wondering if the brass will ever be updated to include a polyphonic ensemble patch similar to the strings ensemble patch? It's the one thing I feel is missing.
When ensemble behavior can be modeled successfully without overwhelming CPU cost - which is what SM Strings does so well - then it will happen.
I think we’re at the forefront of a new realm of modeling tech that is based upon machine learning-derived models of what instruments do in groups, or at the very least something analogous to how flocking behavior is modeled in graphics. Maybe I don’t know enough about it to postulate, but I imagine the difficulties are in teaching a machine how to perceive multiple things happening in a near-coincident manner that’s governed by how the players react to each other and a conductor and the style that’s called for, and managing all of this in real-time. Wondering if/when some enterprising programmer will make use of the power resident in graphics cards to manage this kind of modeling, if that’s even possible.
It's missing because it's not needed -- the way brass instruments are orchestrated and the numbers in which they're instrumentated make the current SM approach doable. The reason ensemble strings had to be developed (imo) was because of the sheer numbers of the players in the ensembles. If you've ever tried doing an ensemble in SWAM, you know what I'm talking about. Most brass sections are well under 20 players, even for really large works. When it comes to doing a 16.16.10.8.8 (for example) sized string section, the SWAM approach/instrument-by-instrument gets to be pretty unwieldy, very quickly.
Also, polyphonic patches exist in the SM instruments because ... strings are polyphonic instruments. Brass ones aren't. That's why in SM strings, it's implemented as a double stop rather than a divisi/ensemble split.
There's also... nothing stopping you from automating multiple brass tracks player by player.
Comments
Would be great
When ensemble behavior can be modeled successfully without overwhelming CPU cost - which is what SM Strings does so well - then it will happen.
I think we’re at the forefront of a new realm of modeling tech that is based upon machine learning-derived models of what instruments do in groups, or at the very least something analogous to how flocking behavior is modeled in graphics. Maybe I don’t know enough about it to postulate, but I imagine the difficulties are in teaching a machine how to perceive multiple things happening in a near-coincident manner that’s governed by how the players react to each other and a conductor and the style that’s called for, and managing all of this in real-time. Wondering if/when some enterprising programmer will make use of the power resident in graphics cards to manage this kind of modeling, if that’s even possible.
It's missing because it's not needed -- the way brass instruments are orchestrated and the numbers in which they're instrumentated make the current SM approach doable. The reason ensemble strings had to be developed (imo) was because of the sheer numbers of the players in the ensembles. If you've ever tried doing an ensemble in SWAM, you know what I'm talking about. Most brass sections are well under 20 players, even for really large works. When it comes to doing a 16.16.10.8.8 (for example) sized string section, the SWAM approach/instrument-by-instrument gets to be pretty unwieldy, very quickly.
Also, polyphonic patches exist in the SM instruments because ... strings are polyphonic instruments. Brass ones aren't. That's why in SM strings, it's implemented as a double stop rather than a divisi/ensemble split.
There's also... nothing stopping you from automating multiple brass tracks player by player.