#193

AMAZING! Love it. The navigation between L and R is much much more fluid now. L+R will be welcomed :slight_smile:

There’s an odd behavior though, once you use the jump with K1, normal values other than 0 or 100% can’t be set with the encoder, only for the jump. […] still playing over this and for some reason is back to normal. I’ll update about this once I find a reproducible pattern.

I see an advantage over the grid here, you can do smooth fade outs of the delay feedback with the encoder. Not that someone with the grid doesn’t have encoders :wink:

The thing I’m missing now it’s a more controllable send as well, but I don’t see an easy way to implement it with three banks and two channels. 16n it is, that take us to…

Would be possible to map two or more parameters with one CC#? I want to control all (a,b,c,in) L sends with one fader and another for R. MIDI learn now overwrites previous mappings.

It feels so much better now, thanks!

Random param: semitone offset still has a ghost param at th bottom under scale.

#194

doooope, glad you got some time with it already!! thank you for the great ideas and feedback :revolving_hearts:

does this mean that if you perform the K1 jump you can’t set the feedback with the encoder again? otherwise, the current logic behind the jump is to either drop/jump to 0% or 100% exclusively – if the current val is 0%, jump to 100%; if the current val is not 0%, drop to 0%.

that’s the system default behavior, but i can cook up a single parameter to control all three, so you can map that single entry with one fader.

apologies, i honestly lost track of this because it wasn’t previously logged as a github issue. i put it in there last night, but if you (or anyone) finds reproducible issues, it makes it so so much easier to track what everyone is finding if it’s logged as an issue (please! thank u!) :sparkles:

2 Likes
#195

This seems too specific for you to code. I’ll be wanting different macros down the line, so I better learn how to do it myself. Master send can be useful for more people tho! Please, let me know which line on the script you create it so I have an example to follow.

Yes, BUT it never happened again after several tries of abusively jumping and moving the encoder. Let’s forget it for now. It’s working as you describe.

Sorry about that, I’ll use github for reporting bugs from now on.

1 Like
#196

Not sure if this is a bug or a specific only to me issue. I have the most recent Norns shield and all other programs respond as they should with all encoders and buttons.

Issue:
CC Beta 4 loads perfectly but K1 is very sporadic in getting back to the Norns interface to edit CC Prams, make selections etc. Sporadic = Sometimes it works with a very quick double tap other times it’s a single tap and other times neither. This is the first beta that I’ve had this issue.

Anyone else having this issue? Regardless I will log it on git hub so Dan is aware of it.

#197

It works as always except for feedback on delay, that overwrites the function to jump.

Btw, @dan_derks, may be nicer just on feedback to eliminate de 0.1s hold so it works with even shorter pulses. For the rest of interactions 0.1s works great!

#198

Hi,

today there was a bit of time to play with cheat codes. Long time no see… I tried to use the beta 4 but K1 seems to give up its function to lead back to the levels/tape/home/parmams page. The only way to cope with that is to login into Fates and reboot. I do not see any obvious error (but with regard to my low level of expertise this does not mean anything).

This is what Maiden says on loading beta 4

script load: /home/we/dust/code/cheat_codes2-beta4/cheat_codes.lua

cleanup

script clear

ERROR (i2c/hp) failed to write
including /home/we/dust/code/cheat_codes2-beta4/lib/cc_pattern_time.lua
including /home/we/dust/code/cheat_codes2-beta4/lib/help_menus.lua
including /home/we/dust/code/cheat_codes2-beta4/lib/main_menu.lua
including /home/we/dust/code/cheat_codes2-beta4/lib/encoder_actions.lua
including /home/we/dust/code/cheat_codes2-beta4/lib/arc_actions.lua
including /home/we/dust/code/cheat_codes2-beta4/lib/zilchmos.lua
including /home/we/dust/code/cheat_codes2-beta4/lib/start_up.lua
including /home/we/dust/code/cheat_codes2-beta4/lib/grid_actions.lua
including /home/we/dust/code/cheat_codes2-beta4/lib/easing.lua
including /home/we/dust/code/cheat_codes2-beta4/lib/midicheat.lua
including /home/we/dust/code/cheat_codes2-beta4/lib/arp_actions.lua
including /home/we/dust/code/cheat_codes2-beta4/lib/rnd_actions.lua
including /home/we/dust/code/cheat_codes2-beta4/lib/cc_musicutil.lua
including /home/we/dust/code/cheat_codes2-beta4/lib/delay.lua
including /home/we/dust/code/cheat_codes2-beta4/lib/euclid.lua
including /home/we/dust/code/cheat_codes2-beta4/lib/midicheat.lua
pset >> write: /home/we/dust/data/system.pset

script run

reading PMAP /home/we/dust/data/cheat_codes2-beta4/cheat_codes/cheat_codes.pmap
m.read: /home/we/dust/data/cheat_codes2-beta4/cheat_codes/cheat_codes.pmap not read.
Engine.register_commands; count: 0
___ engine commands ___
___ polls ___
amp_in_l
amp_in_r
amp_out_l
amp_out_r
cpu_avg
cpu_peak
pitch_in_l
pitch_in_r

script init

pset >> read: /home/we/dust/data/cheat_codes2-beta4/cheat_codes/cheat_codes-01.pset
pset :: /home/we/dust/data/cheat_codes2-beta4/cheat_codes/cheat_codes-01.pset not read.
ERROR (i2c/hp) failed to write
ERROR (i2c/hp) failed to write
output[1] initialized
output[2] initialized
output[3] initialized
output[4] initialized

So I played with the beta3-hotfix, trying to get acquainted with all the wonderful stuff, also to start gradually bringing my cheat cheat up to date (which will take a while).

There is one question so far and I apologize if this has been addressed in this thread or elsewhere and I just did not notice (please point me into the right direction if this has been done already):

I checked out the different timing options and also messed around with random patterns. While doing this I noticed that there seems to be some kind of interaction (?) between recorded patterns and random ones (not sure if this is true). The effect is that once I let CC create random patterns, if I stop the pattern, after some time (I assume it is the distro value so e. g. one or two bars) the pattern (the prevously recorded? the recent random?) plays again automatically. The only way to stop the pattern is to delete it (alt + pattern grid key). I would expect something like that:

  • record patterns persist until the are deleted and can be started/stopped with the pattern grid key
  • a random pattern overwrites a manually recorded one
  • random patterns can be created be setting CC and pushing alt + r button
  • as the pattern key lights up I assume I can use this to stop the random pattern (does not seem to work)

Might it be that there is a mode where recorded and random patterns for one buffer coexist and can be chained?? In which cases do patterns automatically start to play (besides after recording which is obvious)?

Is this a gross misunderstading of the implemented functionality on my side? I would be very grateful for some enlightenment.

#199

hey hey!

the random pattern issues you mentioned are a mix of zero documentation and that some parts are indeed broken and a known issue, though not publicly logged. could you please post it to the github issues so i can report progress on its eventual fix?

everything you outlined is spot on for expectations, some componentsjust literally don’t work as i haven’t had time to focus on it yet :slight_smile:

re: k1, this was experimental — i reduced the hold time from 500ms to 100ms, so that is going to completely shift how you interact with norns. i think it is wayyy more playable in script, but you do just have to do the quickest press on k1 possible to get to the system menus. there is a github issue logged for it (thanks @Quasi!) with some proposed solutions, feel free to add any additional thoughts there :revolving_hearts:

2 Likes
#200

@dan_derks, thanks!

Also for the hint to Github, I definitely will go there and have a look every time I find something or am confused about whatever.

I am not really sure of what to report concerning the pattern issue, I can paste what I have written here but this is not a proper bug report, is it? Would this be enough as a reminder and link for further investigation/progress report?

1 Like
#201

that’ll do ! if you can outline steps to repro, so i can remember and cut to it quickly, that’d be dope :sparkling_heart:

edit: thanks for the clear ticket @mbutz !! super appreciated :slight_smile:

1 Like
#202

Ohhhh yeahhhh!!! At some slower speeds and longer delay times that reverse is a blast!! Very nice!

1 Like
#203

On the delay page of the monome I see 7,12 is the arp latch key. can you add the loop option right above that or is it there and I’m missing it.

Edit. Orrrrr even add the zzz to the delay page?
zz
z

Would be awesome to have the zilch be available in the delay page. Just for playability’s sake.

But for the record as is… this version of CC is so satisfying ANY further requests from me are merely just that. It’s so playable already.

2 Likes
#204

on the list! :hugs:

2 Likes
#205

sorry, i was road tripping all day (in ohio rn! edit: we have been taking covid very seriously and are happy to see most of the necessary stops along the way doing well by folks. just realized that without context, this could be read as “woo, super fun road trip without any care for reality or consequences!”) and wasn’t able to spend the proper time on replies :slight_smile:

once the on-norns random pattern stuff is sorted out, this is exactly what the meta sequencer is for! i need to do some video of this and will once the release is out (apologies that it’s vague how to navigate that page), but you can save patterns on the meta page and recall them on the clock using the meta sequencer — random patterns, played patterns, and arps! the settings for each is retained and recalled, so you can have a free-floating pattern going and then recall a quantized pattern and then recall a random pattern and then recall an arc config and then go back to the free pattern.

1 Like
#206

No worries. I was totally satiesfied with your previous reply already :wink:

Oh yes. I have checked this out a while ago. This is a very nice feature indeed!

When I encountered the automatic playback I was just thinking that besides the meta sequencer there was something else going on; but now I know that’s more of a bug than a feature and so I am able to ‘recalibrate’ my expectations and understanding of what’s going on. Thanks!

#207

Hi @dan_derks,

checked out the arpeggiator in beta4 (video around 34:12). Here again some of what I notice can be due to my ignorance but it seems there are some weird things going on as well:

  • it seems there is a hold and a start/stop arpeggiator key (the 2 buttons besides zilchmo 2) but the behaviour is not clear to me, especially in conjunction with the alt key(s); e. g. you can set the pad to hold mode by pressing the start/stop key (the one directly besides zilchmo 2), screen then shows pause and as soon as you press pads you’ll get an arpeggio

Does it make sense to document what I found over at Github or is this a building site with known issues anyway?

#208

hey! good eye — the button has changed since the video (again, apologies for zero beta docs, will be doing a spike on them in the next week), but it should work like this:

  • press arp button (there’s only one, in between the traditional “pad loop” and the leftmost zilchmo 2) to turn on arp mode
  • hold pads and they’ll arp, release and they’ll stop
  • if you are holding pads and press button again, they’ll enter a hold mode and continue arpin’
  • press more pads while in hold mode to add those pads to the arp (alt+pads removes those pads from the arp)
  • if you press button while pads are arpin’ the arp will pause
  • press button while arp is paused and they’ll start playing again
  • alt plus button to clear the arp

if that’s not happening, then there’s a bug — i’ll be able to investigate any repro steps next week. thanks so much!!

3 Likes
#209

Right. I got confused because I also messed around with the loop/1-shot key at the same time as using the arpeggiator…

One more thing: If you are in arp mode via menu the following is possible (feature?):

  • press ALT/alt (global or local) and press arp key
  • screen says pause
  • press pads, create arpeggio and set bank to hold
  • arp key is not on
  • press arp key to light up key
  • press arp key to stop arpeggio

And final edit: This is so much FUN!

1 Like
#210

hey! the UI changes do feel better for sure. i too was thrown by the change in k1 speed re: entering the menu, however i was able to figure it out eventually and it makes the pages that do use k1 as shift feel so much better. if it’s still 100ms in beta 4, you could maybe go up to 125-175, but dropping that time down helps a lot for me personally.

some other stray bugs that i wrote down in my notes, not making a github issue for each as i don’t have steps to reproduce any of the following, only the last one was really bad:

-the local shift per bank doesn’t seem to work work in all cases you’d use shift for

-gird gesture to trigger filter mode for arc doesn’t work in bank with an active euclid mode

-small chance looping pad gets stuck retriggering forever

-random delay send seems to occasionally produce a feedback loop independent from the delay controls (requiring immediately ripping your headphones off level feedback lol). i was trying to tap the grid controls to zero out input and feedback but with random delay send (and maybe random feedback if that’s an option? can’t remember) it just kept coming back

sorry haven’t been able to spend as much time with it as i want to but it’s so much fun.

#211

Hi Dan, was a downsampling/lofi effect on the roadmap for CC? I remember some discussion in one if the earlier threads.

#212 
engine.name = "Decimator"

-- sample rate
  params:add_control("sample_rate", "sample rate", controlspec.new(0, 48000, "lin", 10, 48000, ''))
  params:set_action("sample_rate", function(x) engine.srate(x) end)
  -- bit depth
  params:add_control("bit_depth", "bit depth", controlspec.new(4, 31, "lin", 0, 31, ''))
  params:set_action("bit_depth", function(x) engine.sdepth(x) end)
  params:add_separator()

if you have otis & add this to the beginning of the script i think that’ll do it for the the input. there are some options to abuse the delay to downsample the output

3 Likes