developers.. live MIDI performance VST (Zyklus/Direct)

[maki]

Is it possible to record on all four layers from four different midichannels coming from four separate midi controllers?
Is it possible to record to at least one layer on several Devices at the same time?

[bronswerk]

Is it possible to record on all four layers from four different midichannels coming from four separate midi controllers?

No, not that's impossible, but then you have to define 4 inputs and route them to different destinations. In one of my earlier designs there was a midi input field for each slot (1, not 4), but I abanded it for the time being because there were other issues to deal with. But I admit a global midi in is a little bit poor.

Is it possible to record to at least one layer on several Devices at the same time?

Yes, while you cannnot record 2,3 or 4 layers at the same time on a single slot, recording of a single layer on different slots simultaneously is possible.

On a side note, before everyone is thinking the program is nearly finished, it's not! One of the major problems I have is the chordrecognition part. It is functioning, but there are severe timing problems when the chordrecognition kicks in, meaning there is about 50% chance of a small audio hiccup when you enter a chord. The mechanism for detecting a chord instead of a series of seperate notes is not good enough which leads to false triggering of the chordrecognition part. So it's possible that 3 or 4 quick chordrecognitions in a small amount of time occurs. Chordrecognition is the most time consuming thing in this program, hence there's a chance of glitching the midi output. Not good.

(There are other things on my list such as "Song, Scene" section with the ability to write/read from/to disk, a more easier way of quickly recording sequences, triggering sequences with keys, midi remotecontrol etc.)

[maki]

Is it possible to copy layers between slots?
Is it possible that your chordrecognizing problem can be solved if a program looks at chordrecognition note-on events only at every 1/16 of time and than makes a decision on harmonizing, instead of making quick decisions all the time?
What programming infrastructure are you using for Zyklus development?

[mbncp]

[..]So it's possible that 3 or 4 quick chordrecognitions in a small amount of time occurs. Chordrecognition is the most time consuming thing in this program, hence there's a chance of glitching the midi output. Not good.

I'm not sure it's a good idea to trigger a chord as soon as you receive a key.
There should be a delay waiting for eventually more keys.
Also, for best results it's important that the user triggers the chords always a litlle early, and the app should then quantize them to the next beat, 1/8, 1/16 .. or whatever to avoid glitches.

Btw, how do you recon chords, by going thru a whole list/array ? Is that time/cpu consuming ?

[plastique]

Looks like a great prototype already, in any case. Agreed, CPU usage is probably the biggest opponent to fight against here.

[bronswerk]

Is it possible to copy layers between slots?
Is it possible that your chordrecognizing problem can be solved if a program looks at chordrecognition note-on events only at every 1/16 of time and than makes a decision on harmonizing, instead of making quick decisions all the time?
What programming infrastructure are you using for Zyklus development?

First question, no. And to clarify some things, chordrecognition only happens when a new chord arrives. And yes, only note-on events are involved. Programming infrastructure? I'm not sure what you mean here. The program is made with Max/Msp and some modules programmed in Java, also in Max/Msp.

[maki]

Is it possible to triger playback of several sequencers or layers by hitting one button?
How is looping implemented? Sponateous performance often results that some note on events can come slightly before loopstart point and some note off points can come just behind loopend point. Playback of those midi buffers does not reproduct those necessery note ons and note offs, often resulting in hanging notes and dropped notes. How did you solve this problem?

[bronswerk]

[..]So it's possible that 3 or 4 quick chordrecognitions in a small amount of time occurs. Chordrecognition is the most time consuming thing in this program, hence there's a chance of glitching the midi output. Not good.

I'm not sure it's a good idea to trigger a chord as soon as you receive a key.
There should be a delay waiting for eventually more keys.
Also, for best results it's important that the user triggers the chords always a litlle early, and the app should then quantize them to the next beat, 1/8, 1/16 .. or whatever to avoid glitches.

Btw, how do you recon chords, by going thru a whole list/array ? Is that time/cpu consuming ?

When you hit a chord very precise the triggering will happen once, but in practice this is not the way you want it. And you'r right about that there should be a small delay for detecting a chord. Max already has some tools for that onboard.

The chordrecognition part that actually decides of a chord is C minor or F augmented or B dim etc. is done by a third party object, but sadly this object is bugged as hell, at least for the Windows variant. The maker was kindly enough to make a version for me specific that doesn't crash Max when saving my program, but a cut/paste of this object still hangs Max. I don't know the innerworks of this object, but I assume that all double notes (2 times a C for example) are deleted, and all notes are squeezed into a one octave range for the interval relationship and compared with a list or something.

And sending a chord ahead is already my second nature.

[bronswerk]

Is it possible to triger playback of several sequencers or layers by hitting one button?
How is looping implemented? Sponateous performance often results that some note on events can come slightly before loopstart point and some note off points can come just behind loopend point. Playback of those midi buffers does not reproduct those necessery note ons and note offs, often resulting in hanging notes and dropped notes. How did you solve this problem?

Triggering several layers at once is yet not possible, but I'm going to make an "Song/Scene" section so the entire layout/settings of all slots can be stored in a "Scene". I had this already in an earlier version.

Looping is implemented on a beat basis. You can set the number of beats of a loop on forehand (implemented, see the "Loop" field each slot have) or just record something and when recording ends, by going out of record mode, the loop length is automatically set (see for eaxmple a "Loop" field with the description "As recorded", but this is not implemented yet).

Now the loop/note events in or outside the loop range with possible hanging notes... that was a little bit trickier to solve. But the solution is relative easy. Just store note events as a *note-on with a specific duration* instead of seperate note-on/note-off events. Ok, now the problem has shifted to the duration part of it, so one must keep track of note-on's (and starttime) and as soon as the corresponding note-off arrives then the difference (in time) between them is the duration in milliseconds. There's a bit more to it, but this is the principle.

[mbncp]

[..]I don't know the innerworks of this object, but I assume that all double notes (2 times a C for example) are deleted, and all notes are squeezed into a one octave range for the interval relationship

Pretty much the way I made it.
I generate a 12 bit value depending on the keys being hold. (C = 2^0, C#=2^1, D=2^2,...)
Ex: d maj = d + f# + a = 2^2 or 2^6 or 2^9 = 580 (1001000100 in binary)
then I right shift until the lowest note is C (number and 1 = 1)(in this case twice so I get 145, binary = 10010001).
Then the quickest way is to use an array of 4096 (2^12) 16 bits integers (uses about 65 kbytes) and access directly the chord id, in this case a C Major (2^0 or 2^4 or 2^7 = 145), but as I shifted twice it's a D Major.

Even using java this should be pretty fast.

[MaxSynths]

It seems interesting, anyway there are too many controls, I think.
You must consider the Zyklus as a starting point and thr Direct box as his evolution. Have you ever read the interviews to Marshall (the man behind Vangelis' Direct Box)on Albedo magazine?

[bronswerk]

It seems interesting, anyway there are too many controls, I think.
You must consider the Zyklus as a starting point and thr Direct box as his evolution. Have you ever read the interviews to Marshall (the man behind Vangelis' Direct Box)on Albedo magazine?

Too many controls? If you know were to cut corners I would like to know them. Funny you mention Bill Marshall. The program I have so far was likely not possible if he wasn't behind the scenes supporting me.

[MaxSynths]

Well there must be something strange then... The first version of the Direct box (not that giant amount of useless boxes Vangelis started to use later) was way too simple and useful.

Does Marshall is providing direct informations to you? This is against the accords with Vangelis. I think he will be not so happy to know this.

[bronswerk]

Well there must be something strange then... The first version of the Direct box (not that giant amount of useless boxes Vangelis started to use later) was way too simple and useful.

Does Marshall is providing direct informations to you? This is against the accords with Vangelis. I think he will be not so happy to know this.

No, Bill Marshall never did say anything about how Direct worked. He was very strict about that.

Now, not to many people will know this, but the original Zyklus Improvisor project was about halfway it's development when it sadly ended. Bill and I worked together for about 4 months. Of course, Bill did the programming and I was his testperson so to say. Unfortunately Bill was too busy with his daily job to finish it. But I still have those early versions on my computer. Anyway, it's not that strange that when there's a certain problem I have with MY version of Improvisor (not Bill's) I can ask Bill how he thinks about it.

[MaxSynths]

Well this piece of software seems very interesting, really.
Sorry, didn't read the whole thread: what are the plans for the future? When will be released, how much it will cost?