RapidComposer v4 beta feedback and discussion (locked)

[sj1]

One other idea for clarification purposes, rename "Markov Generator" to "Markov Generator (from MIDI file)".

Does "Markov MIDI Generator" sound good?
Because I am planning to add a Markov Rhythm generator soon, that takes rhythm from existing MIDI files which you can apply to anything.

Well, honestly, I think the name text "Markov MIDI Generator" overlooks the point and does not achieve the clarification needed.

The point I'm trying to make is that the Markov Generator is not a ready-to-go Generator on its own, but must be supplied with a MIDI file first, as a separate operation, prior to being able to generate anything. Otherwise, it just presents as a blank mystery, suggestive of malfunction. I have suggested a way around that, which you did not comment on.

If I understand correctly your intentions re: Markov Rhythm generator then I would apply the same logic and call that "Markov Rhythm Generator (from MIDI file)".

I realize my suggested name is longer and the end of it may be hidden if the right-side browser pane is not widely expanded. Nevertheless, if the right-side browser pane IS expanded, it will be seen and it does communicate what is necessary to be communicated here (IMO).

Is there an even shorter way to accurately and reliably communicate that this object requires a MIDI file as input? (unlike the others)

Maybe "Markov Generator (mf)", and "Markov Rhythm Generator (mf)".
Or "Markov MIDI Generator (mf)", and "Markov Rhythm Generator (mf)".
Or "Markov Phrase Generator (mf)", and "Markov Rhythm Generator (mf)".

Indeed, there might be more instances in the future where such (mf) notation would apply.

Of course, all those other current generators are "Phrase Generators" also, so letting "Phrase" be understood as the default helps keep names shorter (if that is a concern).

This leaves

"Markov Generator (mf)", and "Markov Rhythm Generator (mf)"

as potentially the shortest names consistent with current practice while still conveying both the difference wrt. the nature of the output and the unique specificity of requiring a MIDI file for input.

[sj1]

today I implemented independent looping in the RC plug-in of the host. So now you can set up a 2-bar loop in RC while you play back your composition in the host if you want.

That's great!

[musicdevelopments]

I think a feature must go. Now that I work on fixing ghost tracks, I realized that ghost phrases can be created in a different track since v2.9, not just in the same track as the original phrase. I don't know how many users have used this, or were aware of this feature, but this makes rendering so complicated with all those dependencies among tracks, it looks awfully complex. Of course ghost tracks also cause dependencies but this together with ghost phrases in other tracks makes everything crazy.

I am also planning to get rid of the 32-bit application and plug-ins for Windows for RC v5.0 (I think everyone uses 64-bit now).
I would love to get rid of RC VST2 plug-ins too...
But VST2 plug-in hosting remains.

[sj1]

I think a feature must go. Now that I work on fixing ghost tracks, I realized that ghost phrases can be created in a different track since v2.9, not just in the same track as the original phrase.

So are you thinking to keep allowing ghost phrases on the same track, but disallow them on other tracks?

[BluGenes]

yea, Atilla, think this one through thoroughly, because losing ghost on other tracks not a good idea at all. I would rather not have ghost tracks, if I had the choice.

I am thinking along the lines that sometimes it is great to have two different instruments play the same thing, ghost can make that happen. But, if I have only ghost tracks to do that with, it would create a crap load of tracks with just one phrase on it for me to do the same thing.

[musicdevelopments]

Understood. I like simplicity but then ghost phrases will remain to be implemented (in other tracks).

So are you thinking to keep allowing ghost phrases on the same track, but disallow them on other tracks?

Yes, that is what I meant.

Thanks!
Attila

[sj1]

BluGenes,

I'm curious to understand your usage.

Are you currently/historically using ghost phrases on other tracks to do the instrumental doubling, but also those other tracks have many different things on them so that you are not "wasting a whole track" (if I may put it that way) just to get a doubled instrument?

Wait, I think it get it - you may have many different ghost phrases on a single track and you don't want to have to put those many different ghost phrases on many different tracks, yes?

[BluGenes]

This is how I use ghost phrases on multiple tracks..

[BluGenes]

I suppose in summary from the video, I think of a track and a bar for that track as a "cell", like a spread sheet. In the video, I only used 1 track for the main idea, but, you could use any combination of the "cells" to become the main idea.

[sj1]

Excellent video BluGenes, thanks. Very sensible workflow, very musical results!

Perhaps the action of ghosting a track (rather than just a phrase) could create a new track wherein all the phrases are ghosts of the phrases on the original. A sort of bulk processing, if you will, rather than having to create ghosts of the phrases one-by-one.

One way of looking at this is that all ghosts (as objects) would be phrase ghosts, but there would be an operation (ghosting a track) that creates many phrase ghosts at once, rapidly .

[sj1]

If track ghosting did work that way, I could also imagine the utility of having some way at creation time to choose between having all the phrase ghosts on the new track initially sounding or initially muted. (Either situation could be preferable at any given moment of creation.)

Under this approach, unghosting a track would unghost all the ghost phrases in it. A decoupling, if you will, from the original phrases.

[sj1]

Are there cons to this approach?

Is there something that it would be unable to achieve as compared to "whole track ghosted, as a track per se"?

[sj1]

It also occurs to me that a ghosted phrase, once unghosted, could potentially be reghosted if the internal link to the original is not discarded by the unghosting operation.

[Mykyndryd_]

Hi All. Late to the party on this one but maybe drop "Markov" from the generator name altogether as it was an experimental feature based on Markov predictability and Attila has made it much much more than that and given us a quite unique function.

How about "The Midi Transformer" or "The Midi Reimaginator" or "The Midi Evolver" or "MidiStein" ("FrankenMidi") or something?

What does everyone think?

Cheers. Mike.

[BluGenes]

Ran your suggestion through ChatGPT and this is what I got back..

Sure! Here are 10 suggestions for funny names for your utility that uses the Markov function to manipulate MIDI data:

1. MIDI Mischief Maker
2. Markov's Melodic Mayhem
3. ChuckleChord MIDI Mixer
4. The Jester's Note Generator
5. Harmonic Hijinks MIDI Magic
6. Rhythmic Roast MIDI Manipulator
7. The MIDI Madness Machine
8. Melody Meme Master
9. Quirky Note Nudger
10. Laughing Keys MIDI Madness

Feel free to mix and match or modify these suggestions to suit your preferences!