Ansible Development and Beta Firmware Discussion

[csboling]

are the Ansible gate out voltages written in stone by the hardware

Yes, these are just GPIO pins on the microcontroller that you can toggle on or off.

[EqualTemperament]

Foiled again!

[rklem]

I think I may have encountered the same issue without anything patched to reset (also using PNW and latest beta firmware).

Not quite certain how to describe the patch. I was running a sequence and stopped it. While stopped, I selected another pattern (without holding the pattern button) and restarted the clock.

The pattern switched and the first note was sustained for longer than expected. This did not occur again the next time the note was triggered.

Not sure if this is the same issue.

Yes, sounds exactly like the same issue. It occurs with or without reset – when the pattern starts on the first note.

[rklem]

You can’t really achieve this with kria alone (really, this is true of many step sequencers that don’t have a second CV out for each track).

Well, you can, you just have to sacrifice another channel for CV. I’m doing this quite often: CH 1 for pitch, CH 2 (or more) for CV modulation.

[EqualTemperament]

How about… a 4th kria alt param that does nothing except store values. And a Teletype op to read and optionally set the values. I know you can already pair Teletype with kria and use Teletype’s pattern storage. But a 4th alt param in kria would be able to have its own loop points, time division, stay easily synced if desired (or go out phase) etc. And could save a Teletype pattern for something else.

So teletype could read this value at the current (or other) position, transform it if desired, send it somewhere else over i2c or one of its analog outs.

Hope I’m not coming off as demanding or anything so please don’t take it that way - just seem to be having a pie in the sky idea day.

[kbit]

This seems similar to what @csboling did with translating the duration parameter to a volume control for Just Friends when using Ansible as a leader. I think being able to read duration as a TT op to use as an additional sequencer source would be pretty great, especially if it wouldn’t take too much to translate what’s already been done

[csboling]

To test this I’m trying the following.

• Teletype output 1 goes to Ansible clock in.
• Script is:

  # M
  TR.TOG 1
  
  # I
  M BPM 240
  
  # 1
  M.ACT FLIP
  

and I’m pressing F1 to start/stop the clock. It appears to me that I can get this to happen intermittently on notes other than the first one, and I wonder if this might just be because Ansible hasn’t had a full clock cycle yet? The clock frequency I think kind of has to get measured to determine some things like note-on duration and ratchet timings, so when the clock starts suddenly it might not be able to calculate the right duration. I can see this behavior quite consistently if I change the clock duration while the clock is stopped and then start it again. I think possibly this could also account for another reported issue where ratchet steps come out wrong, also being clocked by Pam’s in this case.

[rklem]

The clock frequency I think kind of has to get measured to determine some things like note-on duration and ratchet timings, so when the clock starts suddenly it might not be able to calculate the right duration.

Wouldn’t it be possible to store the current clock value and use it on on restart until the new clock has been calculated? This wouldn’t solve the issue with rapid clock changes, but at least the first not length wouldn’t be always wrong when just stopping/starting without changing the clock.

[csboling]

I guess maybe the problem could be that Ansible doesn’t “know” that Pam’s stopped, just that it’s been a long time since it got a clock edge. I’d guess that sort of just looks like a really long clock pulse, which Ansible is doing its best to measure and maybe winding up going with the maximum clock length until the clock starts again. I’m not too familiar with specifics of how Pam’s works, but might be possible to code around this if the reset line stays asserted the whole time the clock is stopped rather than being a single trigger (so that clock measurement is stopped as long as reset is high), and assuming it lets the clock cycle complete when you punch Stop rather than freezing the clock immediately.

Also I’m basing this all on speculation based on reading the code and playing with my Teletype script a little, the exact problem may well be unrelated. I’ll see if I have some more time to fiddle with possible approaches to this problem some this weekend.

[rklem]

I guess maybe the problem could be that Ansible doesn’t “know” that Pam’s stopped, just that it’s been a long time since it got a clock edge. I’d guess that sort of just looks like a really long clock pulse, which Ansible is doing its best to measure and maybe winding up going with the maximum clock length until the clock starts again.

I guess you’re right. When there’s only a short gap between stop/restart the first note is shorter. It get’s longer when the gap between stop and restart is longer.

I’m not too familiar with specifics of how Pam’s works, but might be possible to code around this if the reset line stays asserted the whole time the clock is stopped rather than being a single trigger (so that clock measurement is stopped as long as reset is high)

I’m afraid that’s not possible with PAM’s. It offers four options for a Reset Out:
– ON: +5V while running, 0V on stop
– OFF: always 0V
– 1st Rectangular Modifier: Short +5V Gate pulse on Start (back to 0V while running)
– 2nd Rectangular Modifier: Short(er) +5V Trigger Pulse on Stop (immediately back to 0V)

The last option (short Trigger on Stop) is the only Reset option that works with Ansible Kria. (If a Reset is sent on Start, like option 1, Kria reacts to the reset after it started running, which means, the whole sequence will be shifted (delayed).

[xxsd]

I’m not entirely sure if this is the right spot to post this, but what’s the easiest way to get my hands on an ansible backpack, or any other powered i2c bus preferably in europe/germany? aka where did you find yours @Cobrah?
I’ve already searched a bunch but everythings seems sold out, at least the sources I could find here in various threads.

that being said, big big kudos to everyone developing all these amazing apps!!

[Cobrah]

This is where I ordered mine, but he’s located here in the states in Austin,TX.

[xxsd]

thanks, that was quick. unfortunately they don’t ship to europe, so if anyone can help me out over here I’d be happy!

[csboling]

Okay, I’ve got a patch to try: ansible.hex (361.4 KB - a108fad). When coming out of reset, this measures “now”, subtracts the last stored clock delta from that, and replaces the “last clock tick” time with that, so that when clock_kria_track(t) measures the clock it gets the previous measured delta, instead of the length of the super long “clock” pulse between when the clock stops running and starts again. This seems to fix the problem as tested with my sloppy Teletype attempt to emulate Pam’s.

I think this should give more consistent note durations and ratchet repeats when the clock first starts after being stopped. However, it might affect existing duration/ratchet behavior, especially if your patch is modulating Ansible’s clock frequency and you’re using the reset jack. In such a scenario I’m not sure the “expected” behavior for these parameters fits in my brain (but I really like the sounds currently coming out of the patch I built trying to figure it out). I’m interested to hear people’s thoughts on if this needs to be configurable in the UI/presets file. If so, an extra toggle on the clock page maybe makes sense? Hope this fixes the behavior and doesn’t break any use cases in the process.

[pnyboer]

Hi - I’m new here - Brian pointed me to this thread to get a discussion about getting the Sensel Morph working with Ansible. I work for Sensel, and we’ve had to reach out to several USB host makers - Snyderphonics, Expert Sleepers, Endorphines, Squarp, etc - to help them get their firmware to recognize the Morph.
The issue is that the Morph doesn’t appear as only a USB MIDI device - it shows up as several USB devices (that way we can send keyboard events, gaming events, serial events, etc).

The fix has tended to be fairly quick. Here’s one developer’s feedback:

On my end, I needed to change my code to prioritize midi devices and stop looking once a midi device was found. The issue for me was that the morph reports itself as both a midi device and a hid device. My USB host code wasn’t expecting that a device would do that, so it would find the midi device, but then keep iterating through the USB report device descriptor and then write over the midi device details with the HID device details that were reported afterward.
I needed to change my code to stop searching once it finds a device, and to search for midi devices first, and then it worked. Most middleware for USB host in micro controllers that I have used either don’t iterate through the full descriptor at all (hard coded to look only at device zero) or can’t understand devices that report with two classes, and would need some code hacking to understand a device that reports as belonging to two classes.

There were two things I had to change to get the Morph working.

The first was the maximum number of interfaces per USB descriptor. I
had it set to 5, but the morph needs 7. Obviously on a non-embedded
system with dynamic memory allocation that’s never an issue.

The other was a bit more subtle. The Microchip USB code treats it as a
fatal error if a HID device doesn’t respond to a ‘set idle’. The code
comment is:

             /* SET IDLE failed. As per specification SET IDLE

is optional
* for both boot and non-boot mouse.For e.g. Microsoft mouse
* does NOT support SET IDLE request and STALLs it.
* However for keyboard it is mandatory. */

I had to remove this check for the morph to work.

Should I put this as an issue in github?

[csboling]

Sounds quite similar to this issue @okyeron encountered trying to use a Teensy-based device that also enumerates as both MIDI and HID?

[pnyboer]

Indeed it does sound similar!

[eblomquist]

Welcome Peter, glad to see you on Lines!

[okyeron]

Hi Peter!

Yes - this sounds exactly like the issue I encountered (the one @csboling linked to). I hacked a solution - which I submitted as a PR that you could try.

[pnyboer]

ah, I don’t have an ansible - merely advocating for a customer. I’ll see if they are adept enough to give that a try.