Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Per-instrument Timing, Volume and Pitch Humanization/Randomization #1165

Open
unfa opened this issue Sep 18, 2014 · 25 comments
Open

Per-instrument Timing, Volume and Pitch Humanization/Randomization #1165

unfa opened this issue Sep 18, 2014 · 25 comments

Comments

@unfa
Copy link
Contributor

unfa commented Sep 18, 2014

I think that an arbitrary way to randomize the instrument output a bit could be a very nice function.

I propose adding a special "Humanize" panel with Volume, Timing and Pitch humanize knobs.

The idea is to process the notes before they are sent to the instruments. It'd need some read-ahead for time humanization so some notes can be played earlier.

The pitch humanization would detune every note randomly in some range - prefarably with a gaussian distribution function. This would simulate non-perfect note fretting on guitars.

The ideas could be ectended to create a "randomization" pane for instrument as there are many things that can be set for this.

What do you think?

@tresf
Copy link
Member

tresf commented Sep 18, 2014

Humanization is certainly something I miss from other DAWs. +1

@rubiefawn
Copy link
Contributor

+1. Great for drum sequences too, makes it seem a little less robotic.

On Thu, Sep 18, 2014 at 5:33 PM, Tres Finocchiaro notifications@github.com
wrote:

Humanization is certainly something I miss from other DAWs. +1


Reply to this email directly or view it on GitHub
#1165 (comment).

@unfa unfa changed the title Per-instrument Timing Volume and Pitch Humanization/Randomization Per-instrument Timing, Volume and Pitch Humanization/Randomization Sep 19, 2014
@musikBear
Copy link

partly related to #688 👍

@Sti2nd
Copy link
Contributor

Sti2nd commented Sep 21, 2014

A way to achieve this now is to connect it to a lfo controller and adjust the amount, but it is perhaps to fast changing? Making a lfo "preset" called Humanize could perhaps be a decent solution? I am thinking that it wouldn't need to show up as a lfo, but would be controlled directly from the controller it controls.

@Gps2010
Copy link

Gps2010 commented Sep 22, 2014

That would be awesome.

I remember a demonstration, I once saw at the company I worked at.

It was with an Atari ST and Cubase.

The guy who made the music, made a rhythm on his keyboard , and let us listen.
We complained, it sounded very mechanical. He then took the mouse of the Atari and deliberately, moved one or two notes sligthly of, in timing.

It suddenly sounded like a real drummer LOL

For those that dont know the AtariST and or Cubase)
The big difference with LMMS is that the computer makes the sounds, as in the Atari case the music keyboard made the sound. ( or the midi thingy)
https://www.youtube.com/watch?v=zSzKUcQBR60

@diizy
Copy link
Contributor

diizy commented Sep 22, 2014

Timing changes for notes are a difficult concept, because we can't
predict the future - we work with notes in a "realtime" paradigm, no
matter if the notes are pre-recorded or actually played in realtime.
This means that since we can't predict future notes, we can't move any
of the notes backwards in time. So any timing changes to notes would
have to be forwards-only.

There's additional layer of difficulty in that we have both native notes
and midi notes, and we currently deal with midi notes by throwind note
on events when the native noteplayhandle is constructed. Moving the note
on event away from note construction causes issues with threading (race
conditions) causing weird bugs with midi-based instruments (I've tried).

Volume and pitch randomization are much easier though, they're simply
adding a random value to the volume & frequency properties of the note
(although with midi notes, frequency is limited to discrete keys, so
pitch randomization wouldn't work on those: basically, it would only
work on our native instruments). All we need for randomizing
volume/pitch is pretty much just the UI for it. I suggest adding this to
the FUNC tab in the instrument window, as it would seem like the natural
place for it.

@musikBear
Copy link

diiz , aren this a bit overtopping the actual issue? You are thinking 'live-performance', but in fact its a file or data-write-to-file task- Eg i think note-event 'humanization' as vel as 'Swing' could be done on the mmp. (actually thought about it as i made that automation-track-gadget
eg: https://www.youtube.com/watch?v=yPaOva0ntzs
Swing is typically 1-3/64 opstream 'off', surely that could be 'automated' eg Mark-notes-moves 1->3/64 upstream
Humanization.. well 1..6 /192 randomly added to marked notes posistion..
Wouldent that do it? Filed-data-wise, that is?

@tresf
Copy link
Member

tresf commented Sep 23, 2014

'Swing' could be done on the mmp. (actually thought about it as i made that automation-track-gadget)

Please don't propose these stop-gaps as permanent features. We are talking about a DAW, not an XML parser. These quick hacks are just that -- hacks. They aren't the right way to do things, they're just a temporary solution until the feature is coded into the software. 🎀

-Tres

@diizy
Copy link
Contributor

diizy commented Sep 23, 2014

On 09/23/2014 02:27 PM, musikBear wrote:

diiz , aren this a bit overtopping the actual issue? You are thinking
'live-performance', but in fact its a file or data-write-to-file task-
Eg i think note-event 'humanization' as vel as 'Swing' could be done
on the mmp.

Yeah except that it would be a one-way destructive operation. Once
applied, it couldn't be un-applied or adjusted.

@musikBear
Copy link

musikBear commented Sep 23, 2014

Yeah except that it would be a one-way destructive operation. Once applied, it couldn't be un-applied or adjusted.

True! ⚡


True for the randoming, that is - Swing-pattern would be simple to redo.
__
A different problem is stacked notes chosen Stack-chord-table.
Here there is no user access to the notes in a chord. Only the root is shown, and the other notes in the stacked-chord, is played by lmms.

@tresf tresf added this to the 1.3.0 milestone Nov 30, 2014
@tresf tresf mentioned this issue Sep 25, 2015
@gi0e5b06
Copy link

gi0e5b06@1e3eb1b
humanizer_20171121

@tresf
Copy link
Member

tresf commented Mar 11, 2019

As part of a pruning effort, this enhancement request is archived into a dedicated "Better Workflow" checklist here #4877.

@tresf
Copy link
Member

tresf commented May 6, 2020

@musikBear claims this is in progress, marking and assigning as such.

@messmerd
Copy link
Member

Maybe there should be an option to specify a random seed for generating the humanization. That way you can make a guarantee that your track will sound the same every time it is rendered. And you can choose seeds that sound better to you than others.

@messmerd
Copy link
Member

messmerd commented Aug 22, 2020

And if we implement random seeds, maybe it would also be a good idea to have a control available which lets you reset the seed. This way if you have a pattern containing a riff and you like the way it sounds with the current seed, you can reset the seed every time the riff plays so that it sounds the same every time. It's probably not as important to have, but it should be easy to implement and I think it's good to allow the user more control if they want it.

@Spekular Spekular removed this from the 1.3 milestone Mar 12, 2021
@allejok96
Copy link
Contributor

Some good ideas suggested by @spechtstatt in #6140. What about something like this:

bild

You pull the knob, the notes are humanized. You release the knob, it bounces back to zero and changes are applied.

Good:

  • solves note position problem
  • enables manual edit of humanization
  • live visual feedback

Bad:

  • humanization cannot be "turned off" later

@musikBear
Copy link

i made humanization strumming and some move things, but could not get it on git from a VB
Atm i am trying to get vs2022 to run on windows
This is what i have:
https://www.youtube.com/watch?v=OlBtU0JYvyY

@spechtstatt
Copy link
Contributor

@allejok96: I don't think that the missing "turn off" functionality is really much of an issue as long as you have the possibility to reduce the effect again and/or get back to an initial state.

Best is maybe to show (again) a picture :-)

image

@spechtstatt
Copy link
Contributor

spechtstatt commented Jan 16, 2022

If we have additional functionality like

image

it would also be relatively easy to get to back to an initial state if the range of the knob is not enough anymore.

Of course we may need to think a little deeper which functionality we need. We could e.g. add a kind of inversion of the Right (aka note length) and Left (aka note start) of the picture above which would allow to reduce to the rightmost start and the shortest length respectively.

And if we look at panning and velocity it is anyway possible to set the same value to all selected notes.

@spechtstatt
Copy link
Contributor

spechtstatt commented Jan 16, 2022

Regarding an additional toolbar somehow like this:

image

I would vote for making things more explicite because I can say from my own experience with LMMS until now (a couple of months) that I was not aware of the additional editing functionality until digging deeper during the development - also because I was not expecting it inside a menu with a wrench icon.

And a second reason: I don't know if anyone of you have ever seen this "introductory" youtube video where a guy was opening LMMS and said something like "uh and where is all the stuff?" - he was playing around with bit invader and some of the simpler synths and his final conclusions about the capabilities of LMMS were (in my mind) really, really unfair. BUT: I think he made a point regarding the lack of the presentation of capabilities. @musikBear created also an issue with opening more stuff when you start the program the first time to be more impressive.

@spechtstatt
Copy link
Contributor

@musikBear: I looked at your video and I think this is a great and very important functionality.

What is your opinion on the quantization setting? Do you think it would be an improvement to remove the dependency on the quantization or do you regard this as an advantage or even a must have? I am pretty sure that I have not considered everything in my proposals :-)

@allejok96
Copy link
Contributor

To be fair @spechtstatt I was using LMMS for a couple of months before I discovered the preset collection.

@spechtstatt
Copy link
Contributor

@musikBear: and regarding the effect of the strumming modification of the notes in a single line which you mentioned in your video: I am not sure if you have done this and maybe this is not a problem with your quantization approach, but I think the strumming would need a kind of partitioning algorithm when selecting multiple notes. The algorithm would need to decide which notes have to be grouped together for applying the scrumming. I am thinking about a kind of X/Y "beam" starting from the lowest note up to the left and right.

Not sure if this image is a good representation - the left beam would look at note starts and the right one at note ends only:

image

(or so - just thought very roughly about it, so maybe my approach is flawed)

@allejok96
Copy link
Contributor

The effect should not be linear in a graphic sense, but in respect to note order. E.g. each successively higher note should be shifted with the same amount compared to the previous.

@spechtstatt
Copy link
Contributor

Not sure if I understand this correctly: you mean the grouping decision or the way how the shifting itself is applied?

But maybe this is anyway much easier than I thought in the first place.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests