SWAM
SWAM Player for all swam instruments (Feature Request)

I don't know where to add it, maybe one special topic for Feature Requests.

What about some SWAM player for all SWAM instruments? Something like Vienna Ensemble, where user can stack all (purchased) swam instruments in one place and build own ensemble setup.
For example I want write composition for string quarteto, I load in swam player 2x violins, 1x viola and 1x Cello, load my pressets for each instrument (or change default settings), set up midi inputs and save it. When I use another project I simply load SWAM Player and load my String Ensemble preset which load all my 4x strings and start composing smile

And I think, it can help to create sections more organised, if user can create groups. And nested groups will be super. I don't know what are plans for ensemble/section (like section strings for orchestra) possibilities in swam instruments, therefore I can not write it much about there.

If Audiomodeling is considering some built in reverb for instrument which can do some positioning in space, I think it would be less cpu consuming if all instrument will be use one reverb in this SWAM Player for each loaded instrument and easy positioning displayed somewhere in GUI. If groups will be implemented, user can hide/show and lock (prevent from select instrument) groups, or individual instruments.

_I don't know where to add it, maybe one special topic for Feature Requests._ What about some SWAM player for all SWAM instruments? Something like Vienna Ensemble, where user can stack all (purchased) swam instruments in one place and build own ensemble setup. For example I want write composition for string quarteto, I load in swam player 2x violins, 1x viola and 1x Cello, load my pressets for each instrument (or change default settings), set up midi inputs and save it. When I use another project I simply load SWAM Player and load my String Ensemble preset which load all my 4x strings and start composing :) And I think, it can help to create sections more organised, if user can create groups. And nested groups will be super. I don't know what are plans for ensemble/section (like section strings for orchestra) possibilities in swam instruments, therefore I can not write it much about there. If Audiomodeling is considering some built in reverb for instrument which can do some positioning in space, I think it would be less cpu consuming if all instrument will be use one reverb in this SWAM Player for each loaded instrument and easy positioning displayed somewhere in GUI. If groups will be implemented, user can hide/show and lock (prevent from select instrument) groups, or individual instruments.

What DAW are you using ?

With Reaper such things can be done by using templates and scripts.

Regarding the Reverb, I suppose something like Vienna, providing means to place instruments in a room obviously makes sense. I use a set of two affiliated stereo reverb impulses (free by "Samplicity M7"smile to create a quite realistic placement of the spacial dimension of a drum kit. But of course multiple solo instruments is a lot more demanding

Of course providing both in a common concept would be nice (and doable by Reaper scripts, if an appropriately versatile reverb engine is found. )

-Michael

What DAW are you using ? With Reaper such things can be done by using templates and scripts. Regarding the Reverb, I suppose something like Vienna, providing means to place instruments in a room obviously makes sense. I use a set of two affiliated stereo reverb impulses (free by "Samplicity M7") to create a quite realistic placement of the spacial dimension of a drum kit. But of course multiple solo instruments is a lot more demanding Of course providing both in a common concept would be nice (and doable by Reaper scripts, if an appropriately versatile reverb engine is found. ) -Michael

Yes, I use Reaper. I am aware of templates in Reaper. But imagine, you are changing daw, or you want use some notation program like Notion, how you use template from Reaper? This SWAM Player solve the problem. You are not stuck with Reaper, or another daw, templates and scripts and you can change daw or notation program for project.

I dont like scripting in reaper and I am not understanding it well.

I post some e-mail about Reverb to Audiomodeling when I was asking for something and give them some ideas for SWAM Strings. I think some modeled reverb will be better then any reverb which use impulses. It doesn't must be algorithmic but some modeling reverb which will be tied in to instruments as something non separate. I think this can bring more realism to instrument because intruments are playing in room or somewhere in real space, not in empty space.

Therefore it must have something like one player which contain one reverb, because if you want orchestra/ensemble most realistic, they must play together in one hall/room reverb.

But it is just my opinion, and maybe I am wrong.

Btw. Look at Wallander Instruments (WIVI), it contain Instrument positioning and provide some reverb, I think it is algorithmic. If you want raw sound instrument, you must turn it off by select anechoic room, but it still provide some space, that means if instrument is far from listener, instrument will have less volume. You can use all instruments under one player and build your own ensemble or orchestra (if I know there is no limit how many instruments you can use). If you use unisono for instruments, even if they are perfectly synced (start playing in same time, without some deley), there is no phasing. But WIVI is different technology as SWAM and is old.
Maybe Wallander is better example as Vienna Ensemble.

Yes, I use Reaper. I am aware of templates in Reaper. But imagine, you are changing daw, or you want use some notation program like Notion, how you use template from Reaper? This SWAM Player solve the problem. You are not stuck with Reaper, or another daw, templates and scripts and you can change daw or notation program for project. I dont like scripting in reaper and I am not understanding it well. I post some e-mail about Reverb to Audiomodeling when I was asking for something and give them some ideas for SWAM Strings. I think some modeled reverb will be better then any reverb which use impulses. It doesn't must be algorithmic but some modeling reverb which will be tied in to instruments as something non separate. I think this can bring more realism to instrument because intruments are playing in room or somewhere in real space, not in empty space. Therefore it must have something like one player which contain one reverb, because if you want orchestra/ensemble most realistic, they must play together in one hall/room reverb. But it is just my opinion, and maybe I am wrong. Btw. Look at Wallander Instruments (WIVI), it contain Instrument positioning and provide some reverb, I think it is algorithmic. If you want raw sound instrument, you must turn it off by select anechoic room, but it still provide some space, that means if instrument is far from listener, instrument will have less volume. You can use all instruments under one player and build your own ensemble or orchestra (if I know there is no limit how many instruments you can use). If you use unisono for instruments, even if they are perfectly synced (start playing in same time, without some deley), there is no phasing. But WIVI is different technology as SWAM and is old. Maybe Wallander is better example as Vienna Ensemble.

Hi @Elrond!

Thanks for your valuable post.

As for ensembles, our plan is to release them before the end of 2019.

The idea of making a "SWAM player" with room modeling (i.e. positioning and reverberation) has been considered from the beginning. Things evolved along the way.

As you may know, we are about to release Camelot, a flexible, polyhedric host/MIDI router/live performance manager. Camelot is so versatile that it will be the perfect platform for implementing that "SWAM player", or better a "universal player" with room modeling and other features ;-) .

Best,
Emanuele

Hi @Elrond! Thanks for your valuable post. As for ensembles, our plan is to release them before the end of 2019. The idea of making a "SWAM player" with room modeling (i.e. positioning and reverberation) has been considered from the beginning. Things evolved along the way. As you may know, we are about to release Camelot, a flexible, polyhedric host/MIDI router/live performance manager. Camelot is so versatile that it will be the perfect platform for implementing that "SWAM player", or better a "universal player" with room modeling and other features ;-) . Best, Emanuele

How is Camelot going to work together with a DAW (e.g. Reaper) can it be used as a VST while it embeds other VSTs ?

Is there a Beta test we can contribute to (e.g. by checking it out with Reaper and the SWAM and other VSTs we have ) ?

-Michael

How is Camelot going to work together with a DAW (e.g. Reaper) can it be used as a VST while it embeds other VSTs ? Is there a Beta test we can contribute to (e.g. by checking it out with Reaper and the SWAM and other VSTs we have ) ? -Michael
edited Oct 24 '18 at 5:11 pm

How is Camelot going to work together with a DAW (e.g. Reaper) can it be used as a VST while it embeds other VSTs ?

Camelot is firstly for the live performance management.
The DAW module is not ready yet, but it is on our plans.

Is there a Beta test we can contribute to (e.g. by checking it out with Reaper and the SWAM and other VSTs we have ) ?

We have launched the Camelot Beta Program months ago. We have started collecting beta-memberships at the last Winter NAMM Show, in January. We have collected hundreds beta-testers, closed the subscription and started the first Beta shipping after the Superbooth, last May.
We are going to release the first version of Camelot in a few weeks.

If anyone is interested in beta-testing Camelot, please write to info@camelotpro.com, we will give further infos.

Other resources: camelotpro.com , camelotpro.com/beta

> How is Camelot going to work together with a DAW (e.g. Reaper) can it be used as a VST while it embeds other VSTs ? Camelot is firstly for the live performance management. The DAW module is not ready yet, but it is on our plans. > Is there a Beta test we can contribute to (e.g. by checking it out with Reaper and the SWAM and other VSTs we have ) ? We have launched the Camelot Beta Program months ago. We have started collecting beta-memberships at the last Winter NAMM Show, in January. We have collected hundreds beta-testers, closed the subscription and started the first Beta shipping after the Superbooth, last May. We are going to release the first version of Camelot in a few weeks. If anyone is interested in beta-testing Camelot, please write to [info@camelotpro.com](mailto:info@camelotpro.com "info@camelotpro.com"), we will give further infos. Other resources: [camelotpro.com](https://www.camelotpro.com) , [camelotpro.com/beta](https://www.camelotpro.com/beta)

Sounds rather great but ...

In fact I mostly use Reaper not as a traditional "DAW" but as an audio subsystem for Life playing (including my SWAM instruments). The great stuff about Reaper is that it features a very versatile scripting engine that allows for doing Midi and Audio plugins. This enabled me to set up a Live playing setup with two master keyboards (a Kawai VPC-1 for piano stuff and a 61 key light weighted keyboard - that supposedly will be replaced by a ROLI Seaboard Rise 49) plus a TEC BBC v2 for wind etc sounds. Additionally there is a Behringer XTouch Compact with LED-equipped buttons, Motor-faders and Rotaries for selecting patches and tweaking parameters while playing, and for controlling an X18 Rack mixer - via OSC, and also via scripted Midi plugins in Reaper.

Hence for me, Camelot supposedly would only be of interest as a VST plugin in Reaper, even - and especially because - it would be integrated in a Live setup. So I would be happy to be a Beta tester for the upcoming VST version of Camelot. Please come back if same is in Beta state.

-Michael

Sounds rather great but ... In fact I mostly use Reaper not as a traditional "DAW" but as an audio subsystem for Life playing (including my SWAM instruments). The great stuff about Reaper is that it features a very versatile scripting engine that allows for doing Midi and Audio plugins. This enabled me to set up a Live playing setup with two master keyboards (a Kawai VPC-1 for piano stuff and a 61 key light weighted keyboard - that supposedly will be replaced by a ROLI Seaboard Rise 49) plus a TEC BBC v2 for wind etc sounds. Additionally there is a Behringer XTouch Compact with LED-equipped buttons, Motor-faders and Rotaries for selecting patches and tweaking parameters while playing, and for controlling an X18 Rack mixer - via OSC, and also via scripted Midi plugins in Reaper. Hence for me, Camelot supposedly would only be of interest as a VST plugin in Reaper, even - and especially because - it would be integrated in a Live setup. So I would be happy to be a Beta tester for the upcoming VST version of Camelot. Please come back if same is in Beta state. -Michael

@mschnell our aim, for a scenario like yours, is that Camelot will replace Reaper and not being just another plugin to include in a complex/scripted environment.
If you are searching for just a room modeling software, the MIR is already there.
Camelot purpose is much much more. We are active members of the MMA, working with Yamaha and other partners to design and develop the latest MIDI technologies to facilitate the integration of both hardware and software instruments. Of course, adding a room or an ensemble modeling it is something that matches perfectly our mission smile
I'll inform you as soon as we will have a DAW module that could be of your interest, but that will come later next year.

@mschnell our aim, for a scenario like yours, is that Camelot will replace Reaper and not being just another plugin to include in a complex/scripted environment. If you are searching for just a room modeling software, the MIR is already there. Camelot purpose is much much more. We are active members of the MMA, working with Yamaha and other partners to design and develop the latest MIDI technologies to facilitate the integration of both hardware and software instruments. Of course, adding a room or an ensemble modeling it is something that matches perfectly our mission ;) I'll inform you as soon as we will have a DAW module that could be of your interest, but that will come later next year.

Is a scripting functionality planned for Camelot ? I definitively could use Camelot as a stand alone without that, as you can't foresee how any user would want to design his live setup. Only by scripting, a setup like mine can be brought up, but of course if Camelot would be able to support scripts, I could use it instead of Reaper for this.

Regarding scripts, I would strongly recommend to take a deep look at Reaper. You can download and test an unrestricted software easily for free.

Their JSFX script engine is supposedly the by far fastest available (the scripts are compiled to native code when loading: Reaper is available for Mac, Win32, Win64., Linux32, Linux64, and even ARM Linux), It is crafted to be able to do audio scripts (handling each individual sample) in reatime. It even features FFT, and I was able to do plugins that do multiple channel FFT and run with a CPU overhead of some 5 %. I did scripts that used Midi, audio, and OSC streams. (OSC scripting is not activated in Reaper itself, but there is a (free open source) companion program called “OSCIIBot” that features OSC and Midi interfaces with the same scripting engine. )

The scripting engine’s code is provided as open source – you might want to ask them regarding commercial licensing.

In the user's view, JSFX scripts are loaded and used in Reaper in the same way as VST or other plugins are loaded.

There are hundreds of JSFX scripts for a broad range of purposes done by Reaper uses and provided for free.

There even is a (very well accepted by developers and users) software (to be run within Reaper) that manages online repositories of such scripts. Here each script provides an “about” section with documentation, and same is stored in a database and hence the huge choice of available scripts can be searched, chosen from and automatically be downloaded and installed. (You can search for “mschnell” scripts  …)

If Camelot would feature this script infrastructure it could benefit from that existing pool of helpful add-ons.

Please come back, when I can helpful in any way…

-Michael

Is a scripting functionality planned for Camelot ? I definitively could use Camelot as a stand alone without that, as you can't foresee how any user would want to design his live setup. Only by scripting, a setup like mine can be brought up, but of course if Camelot would be able to support scripts, I could use it instead of Reaper for this. Regarding scripts, I would strongly recommend to take a deep look at Reaper. You can download and test an unrestricted software easily for free. Their JSFX script engine is supposedly the by far fastest available (the scripts are compiled to native code when loading: Reaper is available for Mac, Win32, Win64., Linux32, Linux64, and even ARM Linux), It is crafted to be able to do audio scripts (handling each individual sample) in reatime. It even features FFT, and I was able to do plugins that do multiple channel FFT and run with a CPU overhead of some 5 %. I did scripts that used Midi, audio, and OSC streams. (OSC scripting is not activated in Reaper itself, but there is a (free open source) companion program called “OSCIIBot” that features OSC and Midi interfaces with the same scripting engine. ) The scripting engine’s code is provided as open source – you might want to ask them regarding commercial licensing. In the user's view, JSFX scripts are loaded and used in Reaper in the same way as VST or other plugins are loaded. There are hundreds of JSFX scripts for a broad range of purposes done by Reaper uses and provided for free. There even is a (very well accepted by developers and users) software (to be run within Reaper) that manages online repositories of such scripts. Here each script provides an “about” section with documentation, and same is stored in a database and hence the huge choice of available scripts can be searched, chosen from and automatically be downloaded and installed. (You can search for “mschnell” scripts  …) If Camelot would feature this script infrastructure it could benefit from that existing pool of helpful add-ons. Please come back, when I can helpful in any way… -Michael
edited Oct 25 '18 at 10:42 am

As for ensembles, our plan is to release them before the end of 2019.

Thanks for info, I am excited how new string ensembles will sounds.

As you may know, we are about to release Camelot, a flexible, polyhedric host/MIDI router/live performance manager. Camelot is so versatile that it will be the perfect platform for implementing that "SWAM player", or better a "universal player" with room modeling and other features ;-) .

Yes, I know. If I may ask, you planned integrade "SWAM player" into Camelot, or it will be separate product?

And I forgot mention, "SWAM player" should be as VSTi and standalone version. Both version will be great, but if only one, I will decide for VSTi, but that's me, maybe others have opposite opinion.

> As for ensembles, our plan is to release them before the end of 2019. Thanks for info, I am excited how new string ensembles will sounds. > As you may know, we are about to release Camelot, a flexible, polyhedric host/MIDI router/live performance manager. Camelot is so versatile that it will be the perfect platform for implementing that "SWAM player", or better a "universal player" with room modeling and other features ;-) . Yes, I know. If I may ask, you planned integrade "SWAM player" into Camelot, or it will be separate product? And I forgot mention, "SWAM player" should be as VSTi and standalone version. Both version will be great, but if only one, I will decide for VSTi, but that's me, maybe others have opposite opinion.

Just a current example of the flexibility of the Reaper infrastructure including the scripting feature that might be especially of interest here:

See -> https://forum.cockos.com/showthread.php?t=212551

"kilna", another user of Reaper and member of the Reaper Forum community, uses ROLI keyboard blocks for live playing. He wants to take full advantage of the Midi MPE data this system can create while intending to use non MPE aware VSTIs, which (e.g.) are only able to receive on MIDI channel 1. While the Reaper Midi Routing system allows for modifying the channel on the fly, he wanted to avoid utilizing 15 different tracks (DAW slots) for the voices but combine the patches functionality in a single track.

Now Reaper extends the paradigm of 16 Midi channels by adding four bits for a Midi "Bus" to allow for 256 Midi Channel/Bus combinations with the internal Midi messages (the Midi Routing system can set and make use of the Bus). Of course the standard (VST-) plugins don't see the Bus, but their Midi input can is pre-filtered according to the Bus and their output is "sent" to a dedicated bus.

A Reaper JSFX script sees the messages from all buses, and provides the programmer with the bus number. When sending a Midi message the script can set the bus it is aimed to.

With this, during last week, I helped kilna (see the Reaper Forum Thread mentioned above) to create a JSFX that distributes the incoming MPE Midi messages according to their channel to Midi buses in a flexible way allowing to easily create a setting of multiple instances of MPE-ignorant VSTis of any kind that is easy to integrate in a live setup of many selectable patches.

All this could not be foreseen by the creator of the infrastructure software (DAW) but happily they provided their users with the means to extend the functionality in any direction. So the is just an obvious example, completely different things can be done by Midi and audio scripting to make an infrastructure software such as Reaper or Camelot usable for unforeseeable purposes, making advanced users happy smile .

-Michael

Just a current example of the flexibility of the Reaper infrastructure including the scripting feature that might be especially of interest here: See -> https://forum.cockos.com/showthread.php?t=212551 "kilna", another user of Reaper and member of the Reaper Forum community, uses ROLI keyboard blocks for live playing. He wants to take full advantage of the Midi MPE data this system can create while intending to use non MPE aware VSTIs, which (e.g.) are only able to receive on MIDI channel 1. While the Reaper Midi Routing system allows for modifying the channel on the fly, he wanted to avoid utilizing 15 different tracks (DAW slots) for the voices but combine the patches functionality in a single track. Now Reaper extends the paradigm of 16 Midi channels by adding four bits for a Midi "Bus" to allow for 256 Midi Channel/Bus combinations with the internal Midi messages (the Midi Routing system can set and make use of the Bus). Of course the standard (VST-) plugins don't see the Bus, but their Midi input can is pre-filtered according to the Bus and their output is "sent" to a dedicated bus. A Reaper JSFX script sees the messages from all buses, and provides the programmer with the bus number. When sending a Midi message the script can set the bus it is aimed to. With this, during last week, I helped kilna (see the Reaper Forum Thread mentioned above) to create a JSFX that distributes the incoming MPE Midi messages according to their channel to Midi buses in a flexible way allowing to easily create a setting of multiple instances of MPE-ignorant VSTis of any kind that is easy to integrate in a live setup of many selectable patches. All this could not be foreseen by the creator of the infrastructure software (DAW) but happily they provided their users with the means to extend the functionality in any direction. So the is just an obvious example, completely different things can be done by Midi and audio scripting to make an infrastructure software such as Reaper or Camelot usable for unforeseeable purposes, making advanced users happy :) . -Michael
edited Oct 26 '18 at 5:57 am

I really do wish Cameron to succeed, but please let me phrase some concerns.

  • There are several products targeting a similar purpose that have been discontinued. E.g. "Forte", "Rack Performer" and Native Instruments "Kore"
  • I tested several of such products and found none to be versatile enough to fulfill my needs of integrating the set of controllers and software instruments and other plugins I wanted to use for my live setup. Hence I decided to use Reaper as an infrastructure and do the details by means of JSFX scripts (and other means).
  • Huge complexity : for creating a Live setup for a dedicated purpose, the system needs to be able to integrate a lot of elements:
    • multiple Keyboards (including such versatile ones like Seaboard)
    • Breath controller to work with keyboards (including e.g. the four dimensional BBCv2 )
    • Wind controllers
    • other weird stuff like hand-wave controllers
    • Lots of Midi or OSC based "desktop controller" boards with (illuminated) Buttons, (Led-ring equipped) Rortaries, and (Motor-) Faders to select patches and tweak parameters. This also includes Native Instrument's "Kontroller" keyboards.
    • lots of different workflows, including selectable patches per keyboards, stepping through songs, ...
    • allowing for tweaks to consider the oddities of lots of different VSTs / VSTis. (Kontakt is especially nasty_ pushing a new setup on same creates a huge "silence" delay, using Instrument collections - that allow for switching "programs" per Midi event - is a complex task of it's own).
    • audio input for guitarist, singers, ...
    • allowing for "patch spill over" (a reverb should not stop when patch is changed), while on the other hand non-active VSTs should be put to sleep to save CPU cycles (very important if many plugins are used in a setup).
    • there supposedly is a lot more wich can't be foreseen, part of which I already did accomplish by using JSFX scripts and other extension available for Reaper.

-Michael

I really do wish Cameron to succeed, but please let me phrase some concerns. - There are several products targeting a similar purpose that have been discontinued. E.g. "Forte", "Rack Performer" and Native Instruments "Kore" - I tested several of such products and found none to be versatile enough to fulfill my needs of integrating the set of controllers and software instruments and other plugins I wanted to use for my live setup. Hence I decided to use Reaper as an infrastructure and do the details by means of JSFX scripts (and other means). - Huge complexity : for creating a Live setup for a dedicated purpose, the system needs to be able to integrate a lot of elements: - multiple Keyboards (including such versatile ones like Seaboard) - Breath controller to work with keyboards (including e.g. the four dimensional BBCv2 ) - Wind controllers - other weird stuff like hand-wave controllers - Lots of Midi or OSC based "desktop controller" boards with (illuminated) Buttons, (Led-ring equipped) Rortaries, and (Motor-) Faders to select patches and tweak parameters. This also includes Native Instrument's "Kontroller" keyboards. - lots of different workflows, including selectable patches per keyboards, stepping through songs, ... - allowing for tweaks to consider the oddities of lots of different VSTs / VSTis. (Kontakt is especially nasty_ pushing a new setup on same creates a huge "silence" delay, using Instrument collections - that allow for switching "programs" per Midi event - is a complex task of it's own). - audio input for guitarist, singers, ... - allowing for "patch spill over" (a reverb should not stop when patch is changed), while on the other hand non-active VSTs should be put to sleep to save CPU cycles (very important if many plugins are used in a setup). - there supposedly is a lot more wich can't be foreseen, part of which I already did accomplish by using JSFX scripts and other extension available for Reaper. -Michael
edited Oct 26 '18 at 1:25 pm

@mschnell thanks for the detailed description of reaper and its scripting capabilities.

We know Reaper very well, we have a regular small company license since years and we use it regularly for testing our plugins (along with several other DAWs and hosts).

I understand your point of view of having a super-flexible application where the user can program it almost like a developer... BUT, our vision for Camelot goes in the opposite direction: a musician must focus on the musical performance, not on learning a programming language.

As for the pints you have mentioned:

  • multiple Keyboards (including such versatile ones like Seaboard)
    => Supported. Moreover Camelot allows to play a multi-part hardware synths by MPE controllers, transforming a multi-part synth in an MPE generator

  • Breath controller to work with keyboards (including e.g. the four dimensional BBCv2 )
    => Supported

  • Wind controllers
    => Supported

  • other weird stuff like hand-wave controllers
    => Supported

  • Lots of Midi or OSC based "desktop controller" boards with (illuminated) Buttons, (Led-ring equipped) Rortaries, and (Motor-) Faders to select patches and tweak parameters. This also includes Native Instrument's "Kontroller" keyboards.
    => OSC not yet
    => Native Instruments NKS protocol is not available for hosts yet, if it was we would include it for sure. BTW: SWAM will include NKS support soon

  • lots of different workflows, including selectable patches per keyboards, stepping through songs, ...
    => Supported

  • allowing for tweaks to consider the oddities of lots of different VSTs / VSTis. (Kontakt is especially nasty_ pushing a new setup on same creates a huge "silence" delay, using Instrument collections - that allow for switching "programs" per Midi event - is a complex task of it's own).
    => VST2, VST3, Audio Units fully supported on macOS, Windows (VSTs only), iOS (AUv3 only). Camelot supports the Smart Scene Switching without cutting sounds during a Scene change

  • audio input for guitarist, singers, ...
    => Planned for early 2019

  • allowing for "patch spill over" (a reverb should not stop when patch is changed), while on the other hand non-active VSTs should be put to sleep to save CPU cycles (very important if many plugins are used in a setup).
    => Camelot supports the Smart Scene Switching without cutting sounds during a Scene change

  • there supposedly is a lot more which can't be foreseen, part of which I already did accomplish by using JSFX scripts and other extension available for Reaper.

Pity that your are skeptical about Camelot. Keep in mind that it is not just another "host", it is a software designed specifically for the live performance, supported by "big" partners, namely:

  • FATAR
  • Studiologic
  • Yamaha
  • Nord (Clavia)
  • Roland

With the consulting of several artists and experts involved in the project like Jordan Rudess.

Moreover, Audio Modeling is an active member of MMA (MIDI Manufacturer Association), we will integrate any new MIDI standard coming out. We are still implementing the new MIDI-CI specification.

@mschnell thanks for the detailed description of reaper and its scripting capabilities. We know Reaper very well, we have a regular small company license since years and we use it regularly for testing our plugins (along with several other DAWs and hosts). I understand your point of view of having a super-flexible application where the user can program it almost like a developer... BUT, our vision for Camelot goes in the opposite direction: a musician must focus on the musical performance, not on learning a programming language. As for the pints you have mentioned: - multiple Keyboards (including such versatile ones like Seaboard) => Supported. Moreover Camelot allows to play a multi-part hardware synths by MPE controllers, transforming a multi-part synth in an MPE generator - Breath controller to work with keyboards (including e.g. the four dimensional BBCv2 ) => Supported - Wind controllers => Supported - other weird stuff like hand-wave controllers => Supported - Lots of Midi or OSC based "desktop controller" boards with (illuminated) Buttons, (Led-ring equipped) Rortaries, and (Motor-) Faders to select patches and tweak parameters. This also includes Native Instrument's "Kontroller" keyboards. => OSC not yet => Native Instruments NKS protocol is not available for hosts yet, if it was we would include it for sure. BTW: SWAM will include NKS support soon - lots of different workflows, including selectable patches per keyboards, stepping through songs, ... => Supported - allowing for tweaks to consider the oddities of lots of different VSTs / VSTis. (Kontakt is especially nasty_ pushing a new setup on same creates a huge "silence" delay, using Instrument collections - that allow for switching "programs" per Midi event - is a complex task of it's own). => VST2, VST3, Audio Units fully supported on macOS, Windows (VSTs only), iOS (AUv3 only). Camelot supports the Smart Scene Switching without cutting sounds during a Scene change - audio input for guitarist, singers, ... => Planned for early 2019 - allowing for "patch spill over" (a reverb should not stop when patch is changed), while on the other hand non-active VSTs should be put to sleep to save CPU cycles (very important if many plugins are used in a setup). => Camelot supports the Smart Scene Switching without cutting sounds during a Scene change - there supposedly is a lot more which can't be foreseen, part of which I already did accomplish by using JSFX scripts and other extension available for Reaper. Pity that your are skeptical about Camelot. Keep in mind that it is not just another "host", it is a software designed specifically for the live performance, supported by "big" partners, namely: - FATAR - Studiologic - Yamaha - Nord (Clavia) - Roland With the consulting of several artists and experts involved in the project like Jordan Rudess. Moreover, Audio Modeling is an active member of MMA (MIDI Manufacturer Association), we will integrate any new MIDI standard coming out. We are still implementing the new MIDI-CI specification.

Sounds great.

I definitively will try Camelot some day soon, and I'll recommend trying it to those, who want to do live playing with VST(i)s. There are quite a lot of those in the Reaper forum. You might want to post some messages there and/or send personal messages advertising Camelot to those who asked appropriate questions. (Search the forums for the keyword "LiveConfigs" to find such threads.) I suppose Cockos will not mind, as they seem not to be interested very much in this group of users. I multiple times requested to offer a subforum for Live applications, but this does not seem to happen.

Some details:

Supporting bidirectional Desktop Controllers (Controller surfaces) seems very complicated. There are lots of requests and discussions in the Reaper forums, even though there is some support for some Control Surface devices - e.g. the Mackie Control pseudo-standard - out of the box. Lots of unhappy users and several Projects thriving to improve this. Obviously a moving target.

Oddities of VSTis: obviously a moving target. You can't foresee what those companies do.

You did not explicitly comment on "non-active VSTs should be put to sleep to save CPU cycles (very important if many plugins are used in a setup)." IMHO this is absolutely mission critical, as without that you can't do a complex setup. Smart scene switching needs to decently support this.

Generally you write: "BUT, our vision for Camelot goes in the opposite direction: a musician must focus on the musical performance, not on learning a programming language." IMHO this is not mutually exclusive at all !!!

E.g. Reaper works very well out of the box (as a "normal" DAW, not as an advanced Live playing VST host). Nonetheless it provides means to be extended in any direction for those who are able to do such kind of programming (e.g. creating a new GUI, supporting new workflows, supporting new additional components to be integrated, supporting any kind of automation, even creating versatile audio plugins). I just suggest learning from this (and the fact that e.g. Forte, Kore, and Rack Performer failed, which were "a software designed specifically for the live performance" ), and in fact in the best possible way take advantage of what already has been developed by the Reaper devs. IMHO this would come for limited cost but with great advantages for the future.

Example for unforeseeable stuff: a script three of us are working on right now is aimed to use several instances of not MPE aware plugins with an MP data stream. Here e.g. the count ov voices needs to be reduced.

The list of partners (if necessary at all, as it suggests "excluding all others" ) is not convincing without Native Instruments (being the biggest player in the "Computer Live Music" scene).

Conclusion: If I would have had Cameron with (Reaper-) Scripts, I supposedly would have had to do less than half of the scripting I needed to do for using Reaper as my Live setup. But Cameron without scripts supposedly would not have been usable for me.

Can you elaborate on the "new MIDI-CI specification" ?

-Michael

Sounds great. I definitively will try Camelot some day soon, and I'll recommend trying it to those, who want to do live playing with VST(i)s. There are quite a lot of those in the Reaper forum. You might want to post some messages there and/or send personal messages advertising Camelot to those who asked appropriate questions. (Search the forums for the keyword "LiveConfigs" to find such threads.) I suppose Cockos will not mind, as they seem not to be interested very much in this group of users. I multiple times requested to offer a subforum for Live applications, but this does not seem to happen. Some details: Supporting bidirectional Desktop Controllers (Controller surfaces) seems very complicated. There are lots of requests and discussions in the Reaper forums, even though there is some support for some Control Surface devices - e.g. the Mackie Control pseudo-standard - out of the box. Lots of unhappy users and several Projects thriving to improve this. Obviously a moving target. Oddities of VSTis: obviously a moving target. You can't foresee what those companies do. You did not explicitly comment on "_non-active VSTs should be put to sleep to save CPU cycles (very important if many plugins are used in a setup)_." **IMHO this is absolutely mission critical, as without that you can't do a complex setup.** Smart scene switching needs to decently support this. Generally you write: "_BUT, our vision for Camelot goes in the opposite direction: a musician must focus on the musical performance, not on learning a programming language._"** IMHO this is not mutually exclusive at all !!!** E.g. Reaper works very well out of the box (as a "normal" DAW, not as an advanced Live playing VST host). Nonetheless it provides means to be extended in any direction for those who are able to do such kind of programming (e.g. creating a new GUI, supporting new workflows, supporting new additional components to be integrated, supporting any kind of automation, even creating versatile audio plugins). I just suggest learning from this (and the fact that e.g. Forte, Kore, and Rack Performer failed, which were "_a software designed specifically for the live performance_" ), and in fact in the best possible way take advantage of what already has been developed by the Reaper devs. IMHO this would come for limited cost but with great advantages for the future. Example for unforeseeable stuff: a script three of us are working on right now is aimed to use several instances of not MPE aware plugins with an MP data stream. Here e.g. the count ov voices needs to be reduced. The list of partners (if necessary at all, as it suggests "excluding all others" ) is not convincing without Native Instruments (being the biggest player in the "Computer Live Music" scene). Conclusion: If I would have had Cameron with (Reaper-) Scripts, I supposedly would have had to do less than half of the scripting I needed to do for using Reaper as my Live setup. But Cameron without scripts supposedly would not have been usable for me. Can you elaborate on the "_new MIDI-CI specification_" ? -Michael
edited Oct 29 '18 at 7:38 am

"BUT, our vision for Camelot goes in the opposite direction: a musician must focus on the musical performance, not on learning a programming language."

It's not necessary - or likely - that musicians would do this, but there are open source communities (very active in the realm of reaper) and there are hired consultants for "professionals". Both of which will be able to help making a good system even better, provided the system is open enough to offer the necessary interfaces.

-Michael

"_BUT, our vision for Camelot goes in the opposite direction: a musician must focus on the musical performance, not on learning a programming language._" It's not necessary - or likely - that musicians would do this, but there are open source communities (very active in the realm of reaper) and there are hired consultants for "professionals". Both of which will be able to help making a good system even better, provided the system is open enough to offer the necessary interfaces. -Michael
edited Oct 29 '18 at 2:27 pm

Ranting on ...
The current challenge I face with reaper and scripting for ma Live setup is this:

I am likely to get a ROLI Seaboard Rise 49 for Christmastimes.

Same should be used to play several different kinds of sound engines:

  • its own 15 voice MPE aware synthesizer
  • one monophonic voice such as SWAM Flute
  • one dupohonic engine such as SWAM Cello
  • standard polyphonic (not multitimbral) sound engines such as Kontakt sample instruments or physical modeling Hammond organ plugins
  • sets of multiple (say five) monophonic engines (e.g. SWAM or Kontakt based) to do sets of Orchestra-like sounds.

The patch switching needs to be doen by means of a Midi message from a controller board.

Now the MPE signal from the ROLI needs to be preprocessed and distributed to the multiple instruments in different ways according to the actually selected patch.

How is Camelot supposed to manage this ?

Thanks,
-Michael

Ranting on ... The current challenge I face with reaper and scripting for ma Live setup is this: I am likely to get a ROLI Seaboard Rise 49 for Christmastimes. Same should be used to play several different kinds of sound engines: - its own 15 voice MPE aware synthesizer - one monophonic voice such as SWAM Flute - one dupohonic engine such as SWAM Cello - standard polyphonic (not multitimbral) sound engines such as Kontakt sample instruments or physical modeling Hammond organ plugins - sets of multiple (say five) monophonic engines (e.g. SWAM or Kontakt based) to do sets of Orchestra-like sounds. The patch switching needs to be doen by means of a Midi message from a controller board. Now the MPE signal from the ROLI needs to be preprocessed and distributed to the multiple instruments in different ways according to the actually selected patch. How is Camelot supposed to manage this ? Thanks, -Michael
edited Oct 31 '18 at 6:27 pm

@mschnell firstly you need to know the basic architecture of Camelot.

A "Setlist" can be composed by one or more "Song containers", each "Song container" can be composed by one or more "Scenes".

You can use the "Song container" for representing a song, or you can choose to store a few songs in the container. Why? Because the "Song container" is the place where the resources are loaded and optimized. I.e. if your song need 10 plugins, they are loaded at the beginning. When switching from one Scene to another in the same "Song container" you benefit from the "Smart Scene Switching" with no sound interruption and without waiting for the loading time of a plugin.

The Song and Scene switching can be configured to react to an External MIDI controller, by CC or Program Change.

A "Scene" can be composed by one or more "Layers", each "Layer" contains one or more "Items".

An "Item" can be a plugin or an external device (hardware synth, usually).

A "Layer" can have one or more MIDI inputs, including MPE devices.

An plugin "Item" can be an MPE generator, like Equator, or an MPE-ready monophonic/bi-phonic instrument, like SWAM.

If you want to play a non-MPE plugin with an MPE controller, you need to insert 15 instances of the same plugin and assign a different MIDI channel to each one, starting from 2. Also, you need to set the pitch-bend range of each plugin to 48 semitones.
ROLI provides support on how to configure popular platforms, like Kontakt https://rolisupport.freshdesk.com/support/solutions/articles/36000024514-kontakt-using-the-seaboard-rise-grand-with-kontakt
or Omnisphere https://rolisupport.freshdesk.com/support/solutions/articles/36000024495-omnisphere-using-the-seaboard-rise-grand-with-omnisphere

Moreover, if you have a multi-timbral hardware synthesizer, like Yamaha Montage/MODX/MX, Korg Kronos, Roland JUNO-DS, and so on, you can set the "Layer" to "MPE" and the multi-timbral synthesizer automatically becomes an MPE generator, with the same patch on 15 channels, and the same pitch-bend range (usually +/- 24 semitones, though) for each part. Result: you can play your favorite multi-part hardware device with a Seaboard.

@mschnell firstly you need to know the basic architecture of Camelot. A "Setlist" can be composed by one or more "Song containers", each "Song container" can be composed by one or more "Scenes". You can use the "Song container" for representing a song, or you can choose to store a few songs in the container. Why? Because the "Song container" is the place where the resources are loaded and optimized. I.e. if your song need 10 plugins, they are loaded at the beginning. When switching from one Scene to another in the same "Song container" you benefit from the "Smart Scene Switching" with no sound interruption and without waiting for the loading time of a plugin. The Song and Scene switching can be configured to react to an External MIDI controller, by CC or Program Change. A "Scene" can be composed by one or more "Layers", each "Layer" contains one or more "Items". An "Item" can be a plugin or an external device (hardware synth, usually). A "Layer" can have one or more MIDI inputs, including MPE devices. An plugin "Item" can be an MPE generator, like Equator, or an MPE-ready monophonic/bi-phonic instrument, like SWAM. If you want to play a non-MPE plugin with an MPE controller, you need to insert 15 instances of the same plugin and assign a different MIDI channel to each one, starting from 2. Also, you need to set the pitch-bend range of each plugin to 48 semitones. ROLI provides support on how to configure popular platforms, like Kontakt https://rolisupport.freshdesk.com/support/solutions/articles/36000024514-kontakt-using-the-seaboard-rise-grand-with-kontakt or Omnisphere https://rolisupport.freshdesk.com/support/solutions/articles/36000024495-omnisphere-using-the-seaboard-rise-grand-with-omnisphere Moreover, if you have a multi-timbral hardware synthesizer, like Yamaha Montage/MODX/MX, Korg Kronos, Roland JUNO-DS, and so on, you can set the "Layer" to "MPE" and the multi-timbral synthesizer automatically becomes an MPE generator, with the same patch on 15 channels, and the same pitch-bend range (usually +/- 24 semitones, though) for each part. Result: you can play your favorite multi-part hardware device with a Seaboard.

In fact even without sophisticated additional Midi processing, you can get away with less than 15 instances of a mono plugin for MPE, as you can set the Seaboard to 1..15 voice channels. Regarding Camelot, same would need to send the appropriate Midi messages to the Seaboard to change the mode when a new Scene is selected.

-Michael

In fact even without sophisticated additional Midi processing, you can get away with less than 15 instances of a mono plugin for MPE, as you can set the Seaboard to 1..15 voice channels. Regarding Camelot, same would need to send the appropriate Midi messages to the Seaboard to change the mode when a new Scene is selected. -Michael

Follow-up:

I did some research on how to change the settings in a Seaboard by sending Midi messages to same. I found that it does accept SYSEx messages (usually sent from the "dashboard" application). But this is not officially supported and there is no decent description available. Can you get more information about that ?

-Michael

Follow-up: I did some research on how to change the settings in a Seaboard by sending Midi messages to same. I found that it does accept SYSEx messages (usually sent from the "dashboard" application). But this is not officially supported and there is no decent description available. Can you get more information about that ? -Michael
edited Nov 7 '18 at 6:14 pm
288
18
3
live preview
enter atleast 1 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
With selected deselect posts show selected posts
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft