@garrett: Yeah all the Yamaha keyboards have the same essential style maker algo. Thanks for the encouragement.
TL;DR: StyleMaker algorithm analysis of BIAB; RAS feature priority list; RAS mockup draft; ETA.
BTW I wanted to draw some parallels with BIAB, but for our purposes its way more involved, not in terms of the feature complexity but the time it will take for us to get it right because we are not pro-audio devs as of yet (pro in other things though ).
However, some very important things came out when I was making my own styles in BIAB, I never used this accompaniment feature anyways ever, but I can see it can be a very good jamming tool in RAS.
1) USER EXPERIENCE: Load a style, adjust the tempo to taste and enable Syncho Start in RAS and just press the Chord Pads in the RAS UI or press the MIDI keyboard for chords input. The chords you play will adapt to the style parameters and the music will progress accordingly.
2) STYLE CREATION: Create you own style in RAS inside Renoise. The UI of RAS will show the 5 most important elements for the style - DRUMS,BASS, KEYS, GUITAR & PADS(slow synth).
This recorded pattern will be represented internally in RAS as a pattern list in a row. We can fill each of the pattern boxes with our user patterns. In pattern entry mode RAS will switch to Renoise view and work with the editors (Phrases and Pattern editors) to collect and process data.
DRUMS    
BASS    
PIANO    
GUITAR     
# TRACK 1: Record a 2 bar drum beat. Sound source: drum vst (Kontakt) or just samples in a drumkit layout in Instrument 1.
Choose another pattern box and record the sequence for a fill.
# TRACK 2: Record a 2 bar bass pattern in C Major Scale playing the bass riff as if it was for the C7 chord (music theory reasons, makes it easier to 'transpose' (see modes below)for blues etc).
# TRACK 3: Record a 2 bar piano pattern in C Major Scale with the pattern playing around the C7 chord. You can use other notes as well in the scale if required since RAS will decide finally what to actually play.
We can leave out the guitar and pads for now as even this is suffice for our first working example.
Next, the user has to save the style to disk so that it can be recalled later.
Each pattern box will have a conditions list dialog box where we can further configure the playing conditions like the number of bars to play or when to play in the song section (like after how many bars etc). That dialog can be invoked by a right click on the box itself.
Next, RAS will have the CONDUCTOR section in the UI like INTRO, VERSE A, VERSE B, CHORUS A, CHORUS B, MIDDLE 8, ENDING which are further user customizable. These can be a set of buttons on a horizontal groupbox inside RAS on the main toolbar.
Rest of the work will be done by our algorithms. Looking closely at BIAB I see 3 main modes of 'intelligent' chord analysis for live 'tracking' and 'mapping' of user input. Similar to PSR keyboards but a lot more musical if we get it right and implement it.
MODE A: RAS Noob Mode or Simple Transpose. CEGBb will be transposed for a user F7 chord as FACEb.
MODE B: RAS Smarter Mode or Voice Leading. CEGBb will be transposed for user F7 chord as CEbFA taking into account closer movements to destination intervals.
MODE C: RAS Mimic Mode or Riffs Based. A 2 bar (8 beats in 4/4) pattern with notes stored in the style pattern box as C,C,E,G,Bb,E,G as a short phrase or riff will be played in accordance with validity of notes of the user chord with the current key setting and also taking into account the style 'riff pattern'. Thus an F7 user chord will play as ,F,F,A,C,Eb,A,C in the same rhythm as the style pattern.
That is all there is to it. If our RAS can get to work on a very simple 1 pattern box filled for a very simple style for just drums, bass and piano and can take a user input and RAS uses the MODE A for starters, and it plays in sync with our expectations, we already have an accompaniment system in place. We can then just embellish the RAS code base to include MODE B and MODE C later on. We first and foremost need a very basic working prototype that does not have delays or other issues.
There is another factor to the stylemaker in BIAB, its called 'weights'. It works like this, each of the pattern boxes I mentioned above have a number from 1-9 filled in that dictate the probability of that pattern playing. Again this is something we can certainly implement right after we get the first prototype working and sounding good enough.
BIAB however has one major problem: it is not really a LIVE accompaniment system in that you still have to enter the chords and let BIAB perform ALL this analysis which if you read the manuals and demo the melodist and soloist modules makes sense. If the style or song is familiar to you then of course BIAB will work as an auto accompaniment. The BIAB algo actually 'looks' into the 'future' based on the user input text chords and performs post analysis on the styles pattern generation and note sequences based on things like "if the next chord is a mediant minor to the current chord in the measure, play pattern 7 and not pattern 5 which is the default". It takes into account 2-5-1 progressions and THEN generates the full backing track, which while playing live with our RAS has no way of knowing before hand all this. Of course some amount of intelligence can be programmed, if the user DOES input a 2-5-1 then RAS will be in expectant mode and let a pattern box play accordingly, but that is not what we are looking for right now. BIAB has very strong points in analysis but it does them a posteriori the user has entered all the chords in text form and not LIVE.
RAS DEV FEATURE PRIORITY LIST:
I will post a sample mockup in GIMP later on for the UI.
I also think programming our own sequencer etc is not the best use of time, unless we are looking for a full VSTi conversion. For our purposes RAS must be working in Renoise first. Renoise already does all the transport and navigation and VSTi integration etc so we can concentrate of the more essential components.
1) Lua GUI for RAS.
2) Processing user input for chord analysis.
3) For pattern box filling we can use another Lua function internally to copy paste from the pattern editor instead of making our own capturing mechanism. This also makes good use of the Renoise GUI instead of overly complicating our RAS. Renoise handles MIDI very well and we can leverage on that instead of using external MIDI libraries too soon in this project.
4) Implementing the live 'in sync' transposition (MODE A/B/C) without stopping playback. This will be the second most important feature after the chord analyser, because if this breaks then all we have is a ChordAnalyser or a ChordBuilder (like @joule's tool) which is a step forward but not the real USP for RAS.
5) In RAS mode, Renoise MIDI Input has to be directed in a split fashion where the lead MIDI notes are directed to the synth or piano, but the left range of MIDI notes cannot sound on their own but RAS will fill in those sounds from the style (C-1 to B-2). This is an implementation topic. Internally, I think the best way to go forward with the data mapping of Live Input (via chord builder/chord pads or user MIDI input) and Pattern Boxes is to use the Phrases Editor functions and RAS has to create a new phrase for every new chord played in the analysed template of the pattern from the style that will play. It can use 2 phrases as a double buffering system and write to one and delete the data on the other one going hand in hand and then trigger that particular phrase but also be able to play it from somewhere middle depending on when the user inputs the chord. Renoise will handle all the muilti-threaded playing etc , we just need to capture and process(map) the live input in time for RAS/Renoise to play the live input mapped without glitches.
@joule obviously has a lead on us in terms of having Lua knowledge and a similar component purposed tool getting ready behind the scenes, but it all depends on how quickly we can get upto speed with Renoise API and Lua and everything else in between.
I will take one month time to research the API and learn Lua. Also eventually I will convert RAS into a VSTi so in parallel I have to do other things as well. Also I am building the TOC for the book and will start contacting some publishers and put my pitch forward so I estimate a good 3-4 months before I personally can come up with a working version of something. Plus we have our own lives to live and this is all behind the scenes and not paid work so like Open Source software, we will have to be patient. But from my analysis and prima facie research on the available softwares and hardwares, I am very sure that its totally doable with a little persistence from our end.
Some Renoise dev help is certainly appreciated and if senior devs can come up with a prototype sooner than us, we all win either ways. @danoise and @raul have already said that they are willing to help in the learning process, however, the doing I suppose will have to be us, the new guys, who don't know shit. But it will be fun. I am not the person to give up on things especially when I can learn so much from it.
Proof of Concept Prototype of the Renoise Ztyl Zyztim or RZZ.
Faster to do this on http://moqups.com even if it lacks more advanced Photoshop features.
Features (from top to bottom):
1) Conductor Section
2) Chord Analyzer LCD and current Style/Song Key
2) Pattern manager, with current Tab selection on the Core or the Pattern Manager pattern box area. Conditions TAB will open the pattern box conditions pane. Config tab is for other toolwide settings.
3) ChordPad section for input of chord and chord type while the RZZ is playing.
4) Parts of the GUI can be collapsed or hidden.
Edited by encryptedmind, 27 July 2017 - 06:07.