spiricom / mantamate Goto Github PK

Currently have some code in dev commented out that began to make the temporary octave slider unwritable, but I couldn't figure out where I should be setting the currentMantaSliderMode back to the value saved in prevMantaSliderModeForOctaveHexDisable before I had to leave.

@mulshine you could probably fix this in like half a second

I was just thinking about interesting patches one could make with the Manta sequencer setup.

It got me thinking that we might want to allow an option to interpolate between CV values from one hex to another. So, pretty much glide for not just pitch but also CV. Perhaps even allowing it to be selectable on only some hexes would be really interesting.

I imagine this would be trivial to implement ONCE we get glide implemented, but non-trivial in how we would do this on the UI side of things.

Perhaps, if we cannot find a logical way to allow this to be an easily selectable thing, we could make it a preference and then note glide would glide note as well as CVs?

@spiricom thoughts?

Measure time between input gates, configure a timer to run at some division of that time, allow sequencer steps to happen at timer interrupts.

Timer 1
- Measures time between input gates.
Timer 2
- Based on subdivision/multiplier value, retriggers step. C register is subdivision time. A is small gate/off/low time.
Timer 3
- Same as Timer 2 but for other sequencer.

We merged Range Mode PR since we were merging to test the new hardware, but there are still a bunch of bugs in there (only within range mode though).

It made sense at the time

I cannot remember the details of this bug, perhaps @spiricom could provide some details in the comments 😄

Select and hold down hex. Select other hexes - these are added to the list of hexes to be simultaneously modified by next keyboard or slider update.

@mulshine I think I figured this bit out:

When the top left button is OFF, the slider is supposed to represent CV1

When the top left button is RED, the slider is supposed to represent octave

Currently, the octave buttons are changing the UI for all the sliders in every mode but not changing the values. It IS changing the octave value as we would expect.

However, I think @spiricom decided that the octave should change instantly (ie. not require repressing the note) and right now it still requires the reselect.

Still want this?

Having a manual to explain the more menu-divey functionality would be great.

Utmost emphasis on ease of use, do not make more verbose than absolutely necessary.

When you set a CV value on the top sequencer, the output is updated, but if you go to another step and back to that step it doesn't update back.

Oddly enough, it works fine for the bottom sequencer

OptionMode UI
1 SequencerOne Pitch/Trigger
2 SequencerTwo Pitch/Trigger
3 Full/Split
4
5
6
7 Switch to SequencerOne (FullMode)
8 Switch SequencerTwo (FullMode)

When you toggle a new hex while in Order Mode (order touched), the next cycle through the sequence skips one of the previously toggled hexes. All subsequent cycles are correct.

:O

Similar to how pitched mode shows the notes selected when checked in edit mode.

Create functionality to allow two 16 step sequencers with full step functionality as the normal sequencer.

Step sequencers will each have their own clock to allow independent hex hold lengths.

I don't think it's project related other than that the repo might be missing something needed to build?

@mulshine you might know what's up?

------ Build started: Project: MOUSE_DUAL, Configuration: Debug AVR ------
Build started.
Project "MOUSE_DUAL.cproj" (default targets):
Target "PreBuildEvent" skipped, due to false condition; ('$(PreBuildEvent)'!='') was evaluated as (''!='').
Target "CoreBuild" in file "C:\Program Files (x86)\Atmel\Studio\7.0\Vs\Compiler.targets" from project "C:\Users\Studio Admin\Documents\MantaMate\MOUSE_DUAL\MOUSE_DUAL\MOUSE_DUAL.cproj" (target "Build" depends on it):
	Using "RunCompilerTask" task from assembly "C:\Program Files (x86)\Atmel\Studio\7.0\Extensions\Application\AvrGCC.dll".
	Task "RunCompilerTask"
		Shell Utils Path C:\Program Files (x86)\Atmel\Studio\7.0\shellUtils
		C:\Program Files (x86)\Atmel\Studio\7.0\shellUtils\make.exe all --jobs 4 --output-sync 
		make: *** No rule to make target 'src/utilities.o', needed by 'MOUSE_DUAL.elf'.  Stop.
	Done executing task "RunCompilerTask" -- FAILED.
Done building target "CoreBuild" in project "MOUSE_DUAL.cproj" -- FAILED.
Done building project "MOUSE_DUAL.cproj" -- FAILED.

Build FAILED.
========== Build: 0 succeeded or up-to-date, 1 failed, 0 skipped ==========

@spiricom and I noticed this while testing the new hardware. Good news is it works for Sin,Tri, strange envelope inputs, and normal trigger inputs!

While using the Manta+Mate, I've found I often do a multi-select that I accidentally grab one too many hexes.

@spiricom how do you feel about implementing deselect, where when you hold down a hex to multi select in edit mode, you can then rehit a hex to deselect it as well?

Might require switching the data structure we use for selected hex (I think its a stack now?) but I think it'd be worth it if we agree it fits thematically

When user selects and holds keyboard hex, the sliders become Octave and FineTune for the hexes currently being edited. When user releases, upper sliders back to previous mode.

The octave slider and the octave buttons currently act independently, they should be connected such that hitting down octave button decreases the LED value on the octave slider.

Additionally, the octave changes should change the hex selected right away -- without requiring reselecting the note.

Issue where the octave buttons turn amber when they should always be off

To replicate:

1. Add some notes in play mode
2. Go into edit mode
3. Select a hex
4. Hit down octave key
5. Hit any note key

@mulshine mentioned this is due to a how the top hexes currently just sets the previous hex to amber (in lieu of turning of the red, for example).

PS: Sorry if anyone is annoyed by the issue spam, I just like it to keep track of what I'm doing and keep myself focused on a specific fix.

Stepping gets stuck on a note if we remove a note from the sequence while the sequence is playing that note. Likely an issue in note stack.

Can switch between the global modes and things work as you'd expect.

:D

It'd be cool if we could have a drum sequencer alongside the pitched sequencer. However, this would require using the DAC outputs usually used for the slider CVs.

This was just a thought I had, and should definitely be a "everything else is done already, so let's just add this for lols" type thing.

@mulshine and I were discussing how starting up the Manta+Mate should and we were thinking it made more sense to start in toggle/mode.

Switching between Split and Full modes not yet implemented - currently just glitchy.

@spiricom might fill in more details when he gets a chance.

Just wanted to document hardware issues on here as well so we can be on the same page. (and slightly increase everyone's stress levels of course)

We have a fairly general problem with just touching multiple hexes at once where lights will turn on and stay on when they're not supposed to.

Found it while trying to resolve #12, they're likely related but I figured I'd post this in case they aren't and I forget to later

In order to resolve #16, I was trying to access thefunc_button_states and figure out what I needed to check to ensure we only changed the LED while we were in the red state of the top left function button. However, it seems they're never set to anything? The code is a bit obfuscated:

for(i=0; i<4; i++)
{
    func_button_states[i] = uhi_hid_manta_dev.report[i+49] + 0x80;
}

@spiricom Perhaps you know what is up with this code or know where we should look?

Thanks!

The code is currently a bit entangled with send logic all over the place. Robert Sedgewick would be sad with our poor modularity.

We're making this to work with modular synths, so let's make more modular code 😃

Basic Dual Sequence mode functionality implemented, BUT some UI tweaks to be made.

Hard to describe this problem so:

1. Go into trigger mode, now you're in toggle mode
2. Exit the menu (bottom left button)
3. Hit top right button, entering edit mode
4. Hit top right button again, entering trigger toggle mode
5. This turns the top right button red, and the bottom left button red supposedly to indicate entering the menu? But this doesn't open the menu, the trigger mode interface is still shown
6. Hit top right button again, going back into toggle mode. Notice the bottom left button is still red, and this time it actually enter the menu.

Not sure what of this is supposed to happen and what is just totally wonky

Do we want to be able to do this?

Current implementation is:

1. select first edit hex and hold it down - added to editStack
2. select more edit hexes and they will be added to editStack and display red as well

Sliding fingers across surface without making sure to hold first edit hex down can result in multiple red hexes as well, since sliding produces unreliable note offs. That means the mantamate might think the first edit hex is still down when it is not - sliding away from the first hex doesn't trigger the proper note off.

If we pair this method with one where edit hexes are added to the editStack if they fall within a certain time duration from the previously selected edit hex, we may be able to solve or at least subdue this issue.

Currently modifying a fairly popular LaTeX book template for the manual and just wanted to get some quick thoughts on the format! @spiricom how do you feel about it?

One thing I can already thing of changing is switching "Chapter X" to "Section X" or something similar, but oddly enough I cannot seem to figure out how to change that in the template class I'm using (hopefully stack overflow will get back to me on this)

lshort.pdf

I was thinking of a fairly specific case where someone would want to multi-select in edit mode, therefore holding down their first hex then selecting a bunch of other hexes, but want to continue to select more hexes by holding down a new hex and continuing to add. Currently we can't quite do that since it only keeps adding to the editStack while the FIRST hex is he;d

Somewhat hard to explain but this would be the intended result:

1. Hold down a first hex with your left hand
2. Select more hexes with your right hand to multi-select
3. Hold down a new hex with your right hand
4. Release left hand, continue multi-select with left hand

Not a super common case, so if it's a hassle probably not worth bothering, but I could see a few cases where switching hands would be particularly useful

When adding a new note in toggle mode (AKA play mode), we can change the note of the new added note quickly now. However, when we change the note the old note light stays red so the keybed seems to indicate two notes are playing at once when it is just the second note pressed.

To replicate:

1. Enter toggle/play mode (top right button amber)
2. Add a note
3. Notice that middle C is highlight red
4. Press any note that is not middle C
5. Notice middle C is still red while the other note is also red

Add 303-esque glide on hex notes. Glide position will likely take the position of the rest on the sequencer keyboard and the rest will be moved to the current position of high C.

These may be naturally done one-by-one, so if not all are implemented in one PR please ensure this issue isn't closed until all are done.

• Range mode
• Arpeggiator mode
• Toggle mode
• Start sequence at selected block mode

Implement a composition mode where one can store patterns and then select the patterns via the grids.

A very quick-and-dirty roadmap:

• Implement stored patterns
• Create a stored patterns menu
• Select a pattern plays that pattern - specifically at the end of the current pattern
• Create a button hold combination to select a pattern and play it NOW instead of at the end of current pattern.

Badass LED pattern/sequencer/LOGO/MM/something on startup!! :D crazy light stuffz for fun (and so user is confident thing is workin.)

Seems to happen sometimes when connection is made between manta mate and modular. Maybe a side effect of our weird voltage situation?

• Trigger outputs assignable to hexes (like keyboard mode)
• Trigger outputs assignable from different panels
• New upper hex layout

Noticed this while refactoring. Due to how we were doing function pointers, errors weren't being thrown for calling a function that did not exist.

At the moment, I'm not certain what this actually effects, it seems to be only used in range mode.

OOPS

BTW, I'm going to start treating this repo as follows, in terms of branches:

1. master
   • current release (i.e what we would let other people see/use)
2. dev
   • current state of development (everything commited/pushed on this branch should work). should merge with master only when we really like it.
3. all other
   • for specific fixes and new implementations. should merge with dev when confident that it will work.

I think me and @mulshine are in agreement that the non-function pointer style of pseudo-object oriented C works better.

I'm cool doing the leg work on this cus I kinda like cleaning up code and it gives me something to do when I get stuck on something else.

I propose these rules for our pseudo objects, feel free to disagree and we'll duke it out:

1. Prepend every function name with the module name and _: e.g. myNoteStack.getSize(myNoteStack) becomes Notestack_getSize(myNoteStack)
2. Have pseudo constructors: e.g. Notestack_new()
3. Not forgetting to also incldue Notestack_free(myNoteStack)
4. Have getters and setters as necessary: myNoteStack->notestack becomes Notestack_getStack(myNoteStack). This allows us to only use functions exposed ("hiding" all the internal struct stuff) in the .h and be super cool modular dudes
5. With the above, typedefs become based on the pointer and not the struct itself, because this allows us to abstract our pseudo objects and treat them like normal objects (ie. not have to think about whether or not something is actually a pointer because we just pass it around to functions as it were an object). This is also kinda the more standard thing to do in C
6. We should use enums in some places where macro defines are used (like rangemode and togglemode flags)

This bug seems to be mutating @mulshine.

This now only occurs when you first go into dual mode, then select the first note in dual mode - edit mode and hit the top right butt button to go into dual mode - toggle/play mode. Still super unsure what the heck is causing this.

What do we want to do about these?