regarding patches..

[holo]

hi, some questions..
1. when i set some output value (cv, mod..) in a patch this value is immediately distributed to its destination no matter if this patch is actually active in a pattern or not. is this the way it has to be?


2. that may be a bug? i have patch 00 and 01 which set different values for the same destinations (00 sets cv1 to x and 01 sets cv1 to y). patch 00 is on track 1 and patch 01 on track 2 and both use trigger1 but on different steps. when i change the cv1 setting on one of the patches both tracks output on cv1 what was last set for cv1 no matter which patch.

and feature requests:
3. what about shift-ok to clone a patch?

4. page up and down is unused in the patch editor. why not use it to go to the next or previous patch?

[XORadmin]

1. Yes for now it is the way to be. When i will add the screen for recent track settings, i will remove it from the patch. For now it is a nice add on to directly edit patch values with direct effect.

2. I don't understand well. Maybe you add the project file with this so i can check if it is correct behaviour

3. Yes, on my 2do list

4. This is not as easy as you think. For now the patches are only for the CV/GATE tracks. I already have cartridge prototypes here and those got a completely different patch set which work only on the defined track. So you got to be on the track in order to edit it's setting / automatically detect for new patches which type of 'soundengine' is defined for this track. So this is on my 2do list but somewhere at the point i release the cartridges....same actually for the patterns. Here you already have the difference between CV/Gate tracks and sample tracks. Patterns can't be shared.
To be continued..

[holo]

i try to explain what i was doing, maybe i didnt use patches as intended..
i connected all mod outs and some cv and a trigger to one drum module. then i created a patch for each drum sound including settings for each out and also the trigger to make the one module play a lot of different drum sounds.

when i use one track with a list of different patches in a row it plays nicely,
ad 1. when i edit one of the drum patches all other drum sounds (patches) are affected too at the moment of editing and it sounds weird.
2. when i spread the pattern to have a bass drum patch playin on track 1 and snare for example e on track 2 (on other steps than the bass drum) then the described behaviour happend.. i try to create a project for you ..
3. cool, looking forward
4. but why has editing patches a connection to a particular track? i understand it has for creating but the patch itself could know its type then.

and i forgot request nr 5.. was looking for KILL in the patch editor

edit: and nr 6!: trigger a patch via cv inputs?

[XORadmin]

1 Hmm i will test it here, i think when you edit MOD1 in the patch then only MOD1 should change regardless of the track you are busy with, same for triggers (with numbers) etc....could be a bug

2 yes please, i can't make anything of the description

4 It is more a 'by design' thing i could change in the future. It just that i check in which track i am and then open the patch which gets the track settings behind.

5 Didn't plan to add it

6 most probably not because A: for which track the patch should be triggered and B: what if one choses a patch that doesn't belong to the type of the track?

[holo]

here is the project file..
have both tracks started, look at the cv1 output and try altering the cv1 value for the patch used in track 1 and then go to the other track / patch and do the same. cv1 out stays with the value that was altered before in whatever patch/track.
i thought all outs would update on the steps i added a patch number or did i do something wrong?
when you "merge" both tracks to a single one it works fine.

edit: didnt see your reply ..
i'd like KILL because when you use a late trigger like 02 in combination with a note value it triggers twice.

6. well.. at least for cv tracks it might work fine if only dedicated values for cv1, tr1.. are evaluated. if you are very bored in some distant future when nerdseq already has so many features that it can replace any kitchen machine ..

[XORadmin]

Why not just using the kill command. You got 4 FX for it....

[XORadmin]

I checked the project and now i understand.

I save all last send values for each track to avoid sending always all effects even without any change. And in fact, track 1 is being set to the value only once, same for track 2 and these never change in that track, even though the CV1 output is manipulated from another track, for it's own track nothing changed. The Patches don't know about the feature that eg CV1 or MOD3 belong to another track normally. For the patches it is just a value to set in this track. And for now i have no intentions at the moment to make patches smarter.

Other tests will follow..

[holo]

ad kill command: thats what i did.. for each line i added a patch and that can be a lot for drums. so being lazy i simply asked you to do the work ;-)
also most of the fx list is available in patches, why not having kill too. it'd make nerdseq 0.02% better at least and if you dont want to discuss such a minor feature any longer just tell me you'll do or think about it and i wont harass you about it again before 2019.

regarding patches:  guess there is a reason why you dont just update every value that is set in a patch everytime it comes up in the timeline..

[XORadmin]

I will see what i can do for kill. But not so you are silent until 2019. All input is always appreciated!!

Patches, as i mentioned before. Patches are a totally apart module internally related to the tracks. And Patches don't know anything about the current value of a command, only which was the last send value in this track for the command. By design, tracks doesn't have to do anything with each other. And patches are not aware of the fact that several tracks are from the same type. Designed with the future possibility to use the patches also for the external Expanders where a patch also don't know what the functions are. It only knows some common attributes which are the init Values, Ranges and if it should send it all the time (and some internal stuff).
With the future view to the Expanders (Nerd Sound Adapters) it could be that you connect 2 the same sound cartridges and just think of the common FX type function "Cutoff" if it wouldn't be track related, it would send the cutoffvalue to both of the cartridges...

So, fact: Patches are related to a track, to manipulate functions from another track by the patch is a extra giveaway but in some cases limited. And it will stay like this.

[holo]

hehe, thanks, just saying that my heart wont be broken if you dont implement that kill till asap

ok, i give up on the patches, it seems to be more complex than i thought. i understand that i cannot let a external trigger tell a patch that it should set pitch via cv because it wouldnt know which cv (except for dedicated options cv1,2,3..).
its harder to bend my head around how the relation between tracks, outs and patches might be. i'd need a flowchart :-))