Forum Replies Created
-
Posts
-
I won´t say much about this new mode other than it sounds like a useful and logic addition.
But I have to comment on the way it is presented: That is a textbook example of how to comunicate the sometimes abstract and difficult stuff we talk about. Good to have you in the boat Robert:)
Post edited by: LDT, at: 2008/05/05 22:45
Gabriel, but what about my 1. and 3. ? Is this how it is meant to be?
I do understand the concept of the current mode of operation more now, but I should probably play some more with it (with material as you describe) to fully appreciate it.
Just to exemplify how it collides with another way of making music:
You have a page of 16 steps that contains drums and bass. Think of it as a sampled loop. Now you make a cluster of several copies of this page. The idea is to create new rhythms by stting different page lenghts and repeat numbers to the different copies of the page. But as it is now, this (quite simple stuff) is not possible.Quote:What I propose is to have the "re-trigger" behavior for page lengths <16 and "continuum" behavior for page lengths 16 and more. I have just prototyped it and it makes a good first impression.The continuum mode will probably be missed by some for the <16 page lenghts. Perhaps two modes of page lenght? Continuum ("nice") and Retrigger ("rude").
Quote:I was actually thinking the other way around, as found on DAWs: when selecting a midi track for record in Live or Logic, the DAW will accept incoming MIDI data from whatever channel, and ‘re-channel’ the data to the channel number assigned to the DAW’s selected track.Exactly. I too was a bit surprised to find that I had to change the channel that was going into the Octopus. In my setup it is fairly easy for me to change the channel, because it is routed via a track in Ableton, but if you just have a typical synthesizer going into the Octopus it would be a real pain.
Quote:So when I select an Octo track for record, and the Octo track is set to channel #5, and it records MIDI data emitted by a keyboard over MIDI channel #3, the data will end up on the track having MIDI channel #5, as defined for that track.Exactly. This would really boost the intuitiveness (if that is a word) when recording. The only thing (as I see it) that it would conflict with is multitrack (different midi channels) recording. Maybe we could just keep the current mode as a secondary mode (double click on record?).
But that would mean that you can’t work with a 3/4 meter or 15/16 (or whatever less than 4/4 meter).
Isn’t that a bit limiting?Imagine you had a single page playing, and the page had half its tracks at 1/3 of the main clock speed. What happens to them after 16 steps of the main clock?
a) you can send them back to position one together with the normal speed tracks
b) you can let them continue from where they are so the structure can evolve further – to produce what I quicly called a continuum.
The current implementation favors b) very much, but I can see how both a) and b) are desirable, hence my proposed solution.
Hope I makes a bit more sense now
I have set up a couple of templates in Sonar.
One acts as a 16 tracks to 16 channel (acts as a midi router as well), with an additional track to route the keyboard back into the Octopus. The 16 tracks take inputs only from the port for the Octopus, then the channels are remapped to different synths on different ports.
When the sequencer is not running I use MIDI-OX for routing with the same channel assignments.
The other is similar, it just opens up with the favorite set of plugins, and effects buses, I have et the plugin tracks to receive only on a specific channel (from any port, so that I can switch between controllers).
I usually start with the second template and if needed I copy in the 16 tracks from the first template (in fact now that I think of it I could set them up as template tracks).
For dumping I’d say that using a single track and the "Dissolve part" trick is pretty good. But it’s applicability depends on how many midi ports you are using (and the midi routing needs you may have).
Hello Carl,
Robert is right in that it is a matter of setting up Cubase. I have actually had a discussion recently with another Octopus user, who was so kind to share his solution to the problem. I am no Cubase user either, but I do hope this is helpful for you as well.Quote:Hello Gabriel.A member on the Cubase forum was kind to give me a couple solutions. I send you his answer if there is someone else with a similar problem.
Here’s the soultion to my problem:
"If you just want to record what is coming from the hardware sequencer, then just record it onto one track, select the MIDI part on that track, and from the MIDI menu, select "Dissolve part" … when the dialog appears, choose "Separate channels". You’ll end up then with the original track (which you can mute) and a new track for each channel present in the original. Each of these tracks can now be routed to its own VSTi.
If you want to play things in realtime, or if this is a transfer you will need to do on a regular basis, then a better approach would be to set up a template project with 16 MIDI channels and use the Input Transformer to allow only MIDI channel 1 on track 1, channel 2 on track 2, etc. Then record in the normal fashion and you will find that the MIDI data from each channel will get recorded on the track of the equivalent number. Each recorded track can be set up to play its own VSTi, which is an advantage over the first method, because now you can play the sequencer in realtime and hear (audition) the sounds in Cubase.
The Input Transformer is described fully on page 377 of the Operation Manual.
Ideally you should also set the sequencer’s synchronisation to slave to Cubase, and set your project to the same key signature as the song in the hardware sequencer."
Lars, great point. The way things are, are actually geared towards allowing a playing single page to become a "continuum", as opposed to sending everything back to "square one" every 16 steps (16 is the default page length). Think multiple track speeds and chains etc. So we are talking from two different perspectives.
What I propose is to have the "re-trigger" behavior for page lengths <16 and "continuum" behavior for page lengths 16 and more. I have just prototyped it and it makes a good first impression.
Post edited by: gseher, at: 2008/05/04 07:47
Ok – got it running here and it is cool indeed.. packing it into the next OS release.
Thanks again, Robert!Hi Robert,
yes, the page 80 content is what I was referring to, and the red function is what I was thinking of replacing with the base mode of the random pitch feature.
As far as space goes, UI and data are equally important – without a good UI it’s better not to build anything, and data on step level is "scarce" in the sense of its high multiplier. But it looks like we have a plan now.I like this one too, so I took a look at how to build it in.
The basic version can be done pretty easily: build a chord, set the step to polyphony of 1 and have the pitch be selected at random from the chord.
The cost here is one variation of the multi-trigger mode, namely at the place where you specify whether one or all note-offs are sent for a multi-triggered step. I wonder what your thoughts are on this.
