*SOLVED* Recording notes via cv and gate

[holo]

triggering same notes again doesnt work.

put up my midi to cv interface, connected cv1 and 2, set record settings to cv1-note cv2 gate for my channel and started recording. since i'm not very musical i started playing the same note to check timing and didnt record much but one note and many [] ... [] ..[].. empty notes.
later i learned that playing different notes works much better.

seems that noteoff values [] are triggered via gate and noteon via altering note cv? but the cv interface doesnt change note value after you release a key and it shouldnt too.

my workaround was playing different notes ;-)

[XORadmin]

CV recording actually records changings on the CV input. And if you play the same note then there is no change of the note so it doesn't fill it in.
I understand the issue and it shouldn't be like this. I just have to think of how to solve it as the Inputs record independent from each other and i got to make it smart enough so it knows that a gate recording from another input belongs to the CV (and resets the last note then, and writes the next note-on only when the gate goes on).

[holo]

i think the problem is that it doesnt really record changings of the gate cv input.
would it be possible to have a gate column instead of a trigger/retrigger (move retrigger to fx)?
you could make the gate cover 1 or a view steps and infinity at FF and still utilize [] as noteoff (and maybe even another gate value on the noteoff step to add some there) for longer. a note thats played for 2and a half steps with gate resolving 1 step or less would look like that
c2,FF
-,-
[],77

and you'd have a higher gate resolution then

Edit: or even abandon the noteoff [] completely
Anothr Edit: to me it'd feel best if gate was completely independent from note so it could be utilised for an unrelated gating task while note is used like a mod output.

[XORadmin]

No this won't change. The gate is included in the note and if you don't want it to gate then you add the KILL 0 command.
The trigger is usually independend from gating but can also be used for gating. If you set the trigger to FE then the GATE is on, if you set it to 00 then the gate is off. Rest functions are for the triggering.
Also if you want to have precise gates, then use the KILL command on the same or another step. This can create gates from the range of (and i think even fractions of) milliseconds to whatever you want...that instead of the [ ].
If you want to use the CV as a MOD output, then use the CVx command in the FX column which is completely independed from the Gate (but then not note scaled).

Using Note and [ ] in the Note column covers the basic usage of the gating completely, no extra column needed for that. Also this is like the standard for most trackers since like...forever ;-)

I will get into the recording issue which seems to be the main problem here right now and i am sure to fix it soon.

[holo]

alright, sorry stupid me didnt check the manual properly! KILL seems to be the command i wanted
if thats how trackers work since forever i'm fine with it, i bought a tracker.

but just to explain what i was trying to say..
didnt mean to introduce a new column, but to replace the TR with a Gate column (which would hold the KILL information actually) and the retriggering could be a FX property similar to the sample tracks.
if i have a gate i dont need a trigger because a gate is triggering too.

[XORadmin]

But the Trigger column can already act as a gate.

FE turns the gate on, 00 turns the gate off.

[holo]

there's note, tr and kill which are all into gating. thats a bit confusing. why is it like that, how should i use one ore another way?

also the trigger version of the gate and the retrigger speed share their resolution. of course i'm talking without respect to possible limitations of the system in general which i dont know, just seeing the input values i might think that those could have a better resolution (especially the gating TR) if they would not share a value.

[XORadmin]

I am not running against limitations in the system for some triggering. And even if it would be like this, thats why tracker users are so creative, because of the limitations of their systems
The concept of gates and triggers are 2 different things basically, the only common thing is that they share the same output.

You use gates mostly in combination with notes to gate for example an envelope. You can archieve this in it's basics directly from the Note column. Thats how it works with most trackers and a piano roll is nothing different from other DAWs. Note on/ Note off. To finetune the gating to more than steps, you have several options (like KILL for example).

You use triggers to trigger for example a drum module. It gives in it's basics a short pulse which triggers a drum. No music notes involved here. With the trigger column you have direct access for this very common usage..and you could use the CV and MOD output for some modulations of this. That the trigger is more powerfull and adds several functions in one byte here is very typical for trackers. You can see this kind of combinations in many trackers out there, and i am not only talking about PC trackers. More specifically trackers for old homecomputers where you access directly registers of the internal soundchips. So the trigger covers triggers in different lengths, retriggering in different resolutions and amounts (and the only small issue i have to work on is to derive it from the main clock so one can make exact 1/2, 1/4, 1/8 etc syncronised triggers, for now it is derived from it's own clock which is suitable for the most usage). And additionaly you can set the trigger output on and off (like gate) here so you don't have to touch another column at all. Again direct access here. If you have a bassdrum module connected on the trigger output, then you just add a 10, 20, 30 depending on the desired trigger length and it triggers. Easy to directly program this and see it on the main screen. Then you use it for triggering and not as a gate.

And to get deeper in it, you use some of the features of the FX functions and of course the Tables which give you another flexible way to play with your triggers/gates. And of course you can use triggers/gates combined...

So it's about direct access of the most used and basic features in the first place. I'm not going to change anything about this concept. Though i got some more features on my 2do list which involve manipulations of the gate/triggering.

[holo]

first, i'm not trying to change something since i learned about KILL because i can see that it is no limitation which i thought it is before i learned this.

just trying to understand why such a redundancy is allowed to exist in a developers world. ;-)
sorry to waste your time, you can go on with awesome features now.

[XORadmin]

Well i can tell you...some things grow like this, some talking with people, some stuff i think would be the best (which is of course sometimes not the best practically), limited time, knowledge of other systems, no knowledge of other systems...thats how things work.

Also...if i would only think as a developer, then you would have to put in cryptical code in a uncomfortable system = useless for most of the people...i am sure thats not what you want, haha I am continiously thinking about usability here and make music myself...i'm sure that helps.

Anyway, back to the topic, i will fix the record issue