note offset, what allows to record without quantization, at maximum resolution. It also simplifies implementing what follows âŠ
swing. adjustable globally and per-sequence. Both are multiplied to get the applied swing factor. Swing factor ranges from 0 to 1 (0-100%) . 0% is âno swingâ, the typical 0.5 âMPC swingâ. 100% is 0.75 âMPC swingâ.
humanization: using a normal distribution for generating random offsets for each note. You can adjust the variance, that act as the humanization factor. Humanization should be applied to velocity too. BTW, do you think is it right to use a normal distribution here?
per note âprobability of playingâ, that allows having notes that sometimes play and sometimes not. Combined with a global probability could allow very interesting things. Imagine⊠âchanceâ could be a nice name for this parameter, right?
I know I know, i must focus on releasing Oram ASAP⊠but hell, I want some fun too!!
Humanizing is one of the thing iâve wanted to get done at some point as well, but havenât looked into precisely how iâd want to implement it. Perhaps it could be a configurable curve, but normal distribution seems like a reasonable sort of default, so to speak.
Itâs very interesting to see the different approach to swing youâre taking - iâm going with the traditional drum sequencer style (0% being previous step, 100% being next step, 50% being the unshifted position), but picking a specific style, and doing so deliberately, is important
Similarly with the probability, there, also something iâve been working on recently. The way iâve done it is to implement a probability âsequenceâ which allows for each entry in a pattern to track its probability over time during playback. That allows for things like âplay x, skip yâ and âskip x, play next n% likelyâ style things, rather than only strict percentile probability values that always get chosen for the entry. Just dropping that particular cat amongst your pigeons, because it was fun to implement, and gives a bonkers amount of power
I recorded a new demo. Itâs a single pattern looping. Super simple 4 betas with 4 steps/beat. The pattern is this:
KKCK KKCK KKCK KKCK
5 mins of jamming exclusively with the new zynseq features:
Swing Divisor
Swing Amount
Time Humanization
Velocity Humanization => This is super cool
âNote Play Chanceâ is still unimplemented. A random chance is just the first step for this. I like the idea of setting âPlay Patternsâ, like âXXXOOXXOâ, or using a euclidean generator.
Iâm also thinking of attaching euclidean generators to any step in the pattern, so it uses the number of steps in pattern (for instance) as parameter ânâ and the step position as the âoffsetâ, so only the âkâ is required as explicit parameter. Ideas, ideas âŠ
Iâve not pushed the changes because the new parameters are not saved in the snapshot yet. I hope to do it tomorrow.
At the risk of adding complexity, couldnât we add a great deal of flexibility and Power (similar to the recently introduced driver concept), by letting this offset Factor be specified by the player - there would be presets available, such as a normal distribution, but if a person wanted a different distribution they could supply the routine to modify the timing and velocity of a given note.
So you specify:
Time Humanization Normal
Velocity Humanization Normal
But Normal could be replaced by any other named code, either predefined or player supplied.
Iâm using the word âplayerâ to indicate the user - eg the Musician, or Sound Designer.
Ups! I almost forgot to announce that swing and the rest are now merged in Oram
If you update, you will find these new parameters in the patternâs context-menu:
Swing Divisor
Swing Amount
Time Humanization
Velocity Humanization
Play Chance
And these in the note options:
Offset (% step)
Play Chance
All of them should be saved in the snapshots.
As you can see, swing and humanization are pattern parameters. Iâm thinking about having global parameters too, but itâs not so âeasyâ as you could think at a first glance. Devil is in details and i prefer to see how this work and having some feedback, before going on with the global parameters.
Regarding âPlay chanceâ, itâs implemented per-note and per-pattern, so both parameters are multiplied to get the final âPlay chanceâ. You can get very interesting results playing with both of them.
Regarding âSwing Divisorâ, i probably will change how this parameter works, but iâm still looking for the best way. With this âwayâ, i found some interesting combinations, like this one:
4/4 time signature
swing divisor: 3
swing amount: 43%
Finally, i must say humanization, specially âTime humanizationâ, is not really nice and it needs some extra care. I will be waiting your suggestions and ideas.
I was having some fun with this. I made really simple straight beats and melodies to try and hear the impact of the functions.
Drums: Velocity 100
Bass: Velocity 40, Note Play Chance 70%
Melody: Time Humanisation 100
Iâm hearing the effect on the melody more as I listen back, I didnât notice it as much at first. Adding global velocity (to the drums) immediately created a groove. It would be great if the velocity control was allowed per note as this can allow for really expressive drum pattern creation.
Iâm not very satisfied with time humanization so you can expect improvements in this area along the next days. For the rest, iâm quite happy, and iâve found specially enjoyable velocity humanization and play chance. I will think about adding per-note âvelocity humanizationâ.
If not per-note with the drums, per-voice is also good. Applying velocity humanisation across each voice such as hihats and other percussion would be less work to program than a per-note setting and still very effective to get a nice dynamic sounding drum pattern.
Weâve been working hard to improve the pattern editor user interface, specially the pattern render engine.
Better and faster rendering
Smooth scrolling in both axis
Smooth zoom in both axis
Timeline ticks
Take a look:
If you use the Oram Bookworm version (testing), simply update and start enjoying these improvements. Donât forget to send feedback!!
Notes:
If you are a V5 / MINI-2 owner, you can fast access zoom mode by clicking knob#3 and moving knob#3 & knob#4. Bold click knob#3 to reset zoom to default.
If not, you will find the âgrid zoomâ option in the menu.
Touch action still requires some extra work. Donât report issues with touch, please. We are still working on it!
New update! Touch is fixed in the pattern editor and pitch-zoom gesture has been implemented. Now you can scroll and zoom with 2 fingers. Bold press for dragging notes or editing existing ones, etc.
Iâve also improved the knob control in pattern editor, so now you can:
V5 / MINI-2
rotate knob#1 to change tempo
click knob#1 for entering arranger
rotate knob#2 to zoom the grid
click knob#2 for restoring zoom to default
click knob#3 for editing note paramters (or parameterâs defaults, if no note is selected). This function is also available by bold pushing knob#4, but i want to try something more âagileâ.
I just pushed the latest improvements in the pattern editor. I implemented infinite undo/redo, what itâs super cool!!! Currently it only works in V5/MINI-2 devices, like this:
From pattern editor, you click âALTâ to access history navigation. Arrow keys will change its color to orange (V5 only).
LEFT arrow => undo
RIGHT arrow => redo
DOWN arrow => undo all
UP arrow => redo all
This is the logic behind:
Snapshots are saved at given âchangeâ points: clear, record button push, transpose, etc.
if pattern is playing, snapshots are saved on every loop
If pattern is stopped, snapshots are saved every 5 seconds (default)
Snapshots are only saved if the pattern changed, obviously
Iâm still thinking the best way of implementing the undo/redo workflow in V4 and legacy devices.
5s save point does not feel intutive. I added some notes in quick succession and tried to undo and they all disappeared. I was expecting a per-note undo. Having read the instructions I now understand the logic but it is not intuitive and users are likely to be confused or disappointed. It may be better to use a journal for undo so that every action is recorded rather than overal snapshot.
Also, you do not describe when the undo history is invalidated. Of course that becomes evident (and intuitive) when you use it - as soon as a change is made, that point in the undo history is used as the front and other redo states are lost. This does make sense. We need to get this into the wiki docs and device an undo mechanism in V4.
Regarding if users want note-by-note undo/redo, itâs not so clear. It depends of how users use it, the edit workflow. Anyway, the snapshot history can act as a journal. We could use a shorter time, or save snapshot after each edit action from the UI.
For sure, for live recording, you absolutely donât want note-by-note undo/redo. In this case it save changes on each loop.
Nothing strange. Itâs the normal way on any kind of âdocumentâ editor.
Anyway, there is room for improvement. This is just a first proposal
I tried it and it still feels wrong. I added notes and wanted to remove the last couple but a whole tranche of notes were removed. It may be more frequent that you want to undo something when you are adding notes quickly and hence more likely to include more in the time scale. I recommend that manual input be transactioned after each note. We could retain the per-loop transaction point for live playing. (I think some may want per-note here too but letâs see how it feels. Maybe that could be a config option.)
Regarding V4 workflow - we have few options due to the lack of buttons. (Early V4 and before had no âSâ buttons and some custom builds have no touchscreen so we need to design a workflow that uses just the 4 encoders.) We could use the parameter editor to select Undo Mode but this feels wrong. We could use bold press of encoder 3 (Layer) which is currently unmapped (although that might be a bug - I see that short press to toggle playback seems to be broken). (<<This is now fixed.) Or we could add a context menu option to enter Undo Mode. When in Undo Mode we could use an encoder to scroll through the undo/redo states.
