5.0 and stdm2448 and stdm4896
5.0 and stdm2448 and stdm4896
Anyone who visited sonic core at namm, ask if they have added multiple midi channel capabilities for 2448 or 4896 mixer so you can control more of the controls from a control surface?
Seems like this might be called for on other complex devices like synths.
Seems like this might be called for on other complex devices like synths.
mark winger
Re: 5.0 and stdm2448 and stdm4896
no. there's a good chance of seeing osc or mackie control in the future if all goes well, though.
Re: 5.0 and stdm2448 and stdm4896
don't get too excited.
nothing concrete has been decided that i know of...

nothing concrete has been decided that i know of...
Re: 5.0 and stdm2448 and stdm4896
If by osc you mean "open sound control", I might be able to make that work.
mark winger
Re: 5.0 and stdm2448 and stdm4896
Isn't the mackie hui protocol simply midi? If so, doesnt that mean they would be expanding to handle multiple channels? Or is the hui limited to 1 channel too? (seems pretty limited for a controller like that)
mark winger
Re: 5.0 and stdm2448 and stdm4896
mackie control is the most likely, i would guess(and i AM guessing based on conversations i've had), since there is already a mackie control module in the old SDK and mackie control was planned before the first CW insolvancy. that's why Wolf already has a mixer with M/C, that works quite well. i think the original implimentation was weak. i'm hopeful that the whole system can get a M/C(or better) update.
HUI and Mackie Control are different. M/C is midi on steroids, not "just" midi. it is a two way communication that in it's full operation even tells the controller what it is controlling and it's resolution is superior....HUI is a different protocol than M/C.
HUI and Mackie Control are different. M/C is midi on steroids, not "just" midi. it is a two way communication that in it's full operation even tells the controller what it is controlling and it's resolution is superior....HUI is a different protocol than M/C.
Re: 5.0 and stdm2448 and stdm4896
I'm doubt very much that we'll see OSC built into Scope platfrom 5 when it's released. Definitely something for the future, since it's not as simple as people might think to integrate into Scope. It would need OSC I/O interfacing modules for Scope & would need to be implemented in the sdk in the form of Sonic Core rebuilding the full atom & module library to have compatible I/Os, not to mention integrating it into the core functionality of the sdk. I think it's a very very big job for a small team, but it would certainly be an extra attraction to bring new users to Scope in numbers.
Re: 5.0 and stdm2448 and stdm4896
definitely.
i spoke to Holger and Jurgen at length on the subject, and they were quite open to the idea, but as i said, Mackie Control is much more likely than OSC and neither will be in the initial v5 software afaik.
i spoke to Holger and Jurgen at length on the subject, and they were quite open to the idea, but as i said, Mackie Control is much more likely than OSC and neither will be in the initial v5 software afaik.
Re: 5.0 and stdm2448 and stdm4896
That makes sense.
The more I think about it, they might only have to build the OSC I/O interfacing modules for Scope & the sdk if the new sdk modules contained conversions from OSC to the various signal/information types used within the sdk (and Scope under the hood). ALL Devices would still need to be rebuilt in the sdk with the new OSC interfacing built in though, which would mean all developers remaking their devices or building new OSC compatible versions.
The more I think about it, they might only have to build the OSC I/O interfacing modules for Scope & the sdk if the new sdk modules contained conversions from OSC to the various signal/information types used within the sdk (and Scope under the hood). ALL Devices would still need to be rebuilt in the sdk with the new OSC interfacing built in though, which would mean all developers remaking their devices or building new OSC compatible versions.
- nightscope
- Posts: 686
- Joined: Tue Aug 21, 2007 4:24 pm
- Location: UK
Re: 5.0 and stdm2448 and stdm4896
garyb wrote:no. there's a good chance of seeing osc or mackie control in the future if all goes well, though.

ns
“Women and rhythm-section first!”
- nightscope
- Posts: 686
- Joined: Tue Aug 21, 2007 4:24 pm
- Location: UK
Re: 5.0 and stdm2448 and stdm4896
That sounds like a big hugely time consuming job.Shroomz~> wrote:The more I think about it, they might only have to build the OSC I/O interfacing modules for Scope & the sdk if the new sdk modules contained conversions from OSC to the various signal/information types used within the sdk (and Scope under the hood). ALL Devices would still need to be rebuilt in the sdk with the new OSC interfacing built in though, which would mean all developers remaking their devices or building new OSC compatible versions.

ns
“Women and rhythm-section first!”
Re: 5.0 and stdm2448 and stdm4896
Exactly mate. People would most likely need to pay for it as well. No free Scope software update for that one if it comes in v6 or 7. I'm not entirely convinced that it would be worthwhile for SC to spend time on either unless it was something they had already planned & built into XITE, which it doesn't sound like they have.nightscope wrote:That sounds like a big hugely time consuming job.
Last edited by Shroomz~> on Wed Feb 11, 2009 1:47 pm, edited 1 time in total.
Re: 5.0 and stdm2448 and stdm4896
which is exactly the kind of thing that the guys in S/C love doing, assuming that they can pay the bills by selling product...nightscope wrote: That sounds like a big hugely time consuming job.
Re: 5.0 and stdm2448 and stdm4896
Something that's worth consideration is that only a relatively small number of existing Scope users will be interested in PAYING for new software that supports OSC & that's going to be a problem for anyone that spends serious time implementing it in the platform & plugins. That's probably why it should be something that's only implemented in new hardware, adding an extra incentive for people to buy said new hardware in the future. (just my opinion though & I could easily be very wrong)
Re: 5.0 and stdm2448 and stdm4896
The thing is Stardust; you have a lemur, but not too many Scopers have those. There are definitely some Scopers that use max/MSP that would love to see it, but how many? If a dozen Scopers stick their name here, would that mean that it's worth the time to implement it? I'm not so sure TBH.
Re: 5.0 and stdm2448 and stdm4896
oh, my! i used a bad word again...let's just hope for M/C for now. if we get better, it's even better. the main thing is that a better automation protocol will be needed for the platform to really get the respect and response it deserves and i'm confident right now that S/C is willing to do it, assuming that all goes reasonably well...
Re: 5.0 and stdm2448 and stdm4896
I wouldn't say that Gary, as I'm all for being optimistic about Scope's future (as you know), but maybe people shouldn't be allowed to believe that something like full OSC integration within Scope & all of it's plugins is remotely likely to happen within the next 18-24 months unless it actually/definitely is. As it stands atm, full OSC support in Scope & it's plugins is a complete pipe dream.garyb wrote:oh, my! i used a bad word again
garyb wrote:...let's just hope for M/C for now.
The 'M/C' is already partially implemented as you no doubt know (at least there's some basic interfacing modules available in the sdk). Wolf made new mixers with an implementation of it.
If Wolf did it to the extent that he did, then Sonic Core can too.garyb wrote:if we get better, it's even better. the main thing is that a better automation protocol will be needed for the platform to really get the respect and response it deserves and i'm confident right now that S/C is willing to do it, assuming that all goes reasonably well...
Re: 5.0 and stdm2448 and stdm4896
From my perspective, the xite is currently way beyond my price limit. The current scope hardware is excellent for what I need so if SC wants to sell me something it needs to be 5.0.
At this point other than maybe Vista support, there is no reason for me to upgrade to 5.0. Are there any new features in 5.0 I can't live without? As of now, the only thing I know I am willing to pay the upgrade price for 4.0 to 5.0 would be increased control of the 2448 and 4896 from a midi control surface, but that is not in the release.
It seems to me that there is a great potential for xite to compete against the likes of the large format digital consoles like Digidesign Venue with the right control surface and preamps and be significantly less expensive. But to do it, a control surface needs direct control of all mixing parameters, which is not possible at this point (currently limited to 128 controls on one midi channel)
At this point other than maybe Vista support, there is no reason for me to upgrade to 5.0. Are there any new features in 5.0 I can't live without? As of now, the only thing I know I am willing to pay the upgrade price for 4.0 to 5.0 would be increased control of the 2448 and 4896 from a midi control surface, but that is not in the release.
It seems to me that there is a great potential for xite to compete against the likes of the large format digital consoles like Digidesign Venue with the right control surface and preamps and be significantly less expensive. But to do it, a control surface needs direct control of all mixing parameters, which is not possible at this point (currently limited to 128 controls on one midi channel)
mark winger
Re: 5.0 and stdm2448 and stdm4896
I would like OSC support.
However something like mackie control and other control surface compatibility in the mixers and other devices would be more useful to more people.
(a switcher which changes whats being controlled when you change it on the surface)
However something like mackie control and other control surface compatibility in the mixers and other devices would be more useful to more people.
(a switcher which changes whats being controlled when you change it on the surface)
Re: 5.0 and stdm2448 and stdm4896
Agreed. I am not arguing for a particular implementation, I am asking for any implementation that can be used to accomplish this. (I do think is was short sighted or creamware to only use 1 mini channel per device instead of 1 midichannel per control). As a software engineer (my real job) I cannot see how this would be all that much work.
mark winger