Video

you can u21se the serial port for midi input, if that's the question

It's an arbitrary limit, which we set for the menu: it's hard to reliably touch a discrete positions when there are more than 5 in the limited space of the faceplate. It's possible that for keyboard/sequencer use it wouldn't be too bad to have a few more, but 8 seems like a lot.

they measure capacitance only. With the right geometry of pads you can get touch size which can work as a proxy for touch pressure in certain contexts.

the rightmost module is Bela's Pepper, it is connected over wifi to the same network as the iPad and so what you see on the iPad is the Bela scope, hosted on the Pepper and shown in the iPad's browser.

Nice! Thanks @@oromoiluig

you need to smooth the changing of the delay time across several frames or even blocks to minimise the "jumps" . This is a pretty common approach across time-varying audio effects.

@@oromoiluig Value ramps are good, I just wish I knew the secrets being used in commercial plugins :p

the order of the ranges as you cycle through them is: • 0V:10V • -5V:5V • 0V:5V • -5V:10V • custom range The custom range by default is -2V to 7V (currently), but it can be adjusted by hold-pressing the selector and move the two pointers that appear then. See page 15 of the Gliss manual.

Thanks @@oromoiluig, better explained than manual : )

Sure, all the pads are independent. You can group them as you see fit as long as you interpret the readings appropriately on the host. You can use the CentroidDetection library for that.

To (re)- fill zones, press "b"

@@chair_audio hi, thank you. it's not working. it has no effect... a window pops up called 'Fill All Zones', a time bar fills up but no changes... I wonder why...

Gliss actually ships with the jacks and button at the top, so you don't need to do anything. We currently ship with a second faceplate with the jack and button at the bottom. See 08:42 in the video for an explanation of how to switch this around.

Thanks. I just bought one. The module packs a lot of fun into 4hp. I love the light show too!

The "size" output can be used as a gate by setting touch sensitivity to the maximum. This is shown at 7:47 . The tablet is connected via wifi to the our Pepper module. Relevant signals are routed to Pepper via patch cables, where they are sent to the Bela scope, which is what's shown on the tablet.

Looping a gesture is the default behaviour of Record mode. Check out: 13:49

I don't want it to default. I want to decide whether or not it loops on the fly, without changing modes. Check out the loop function of Soundmachines LS1. Your module is far superior technically but their implementation is better. I think a basic function is missing.

​@@DrRichardScott According to the LS-1 manual, you can hold-press the rec button while recording, after which the playback starts automatically, then press the play button to stop playback. On Gliss you can achieve something very close to that in Record mode, playback type "Clock" and no clock going into the input. This way you can use the button to control start and stop of the recording. This is shown briefly at 19:59 . The detailed procedures is as follows: - press the button once to start recording (equivalent to press and hold rec on the LS-1) - press the button once to stop recording (equivalent to release rec on the LS-1) - press the button three times fast to stop playback (equivalent to press the play button on the LS-1)

Thanks, good to know it is kind of possible, but this also highlights the problem: "press the button three times fast to stop playback". Ask any musician: this function surely needs to be a toggle - on to loop, off to stop? Pressing something 3 times to stop something happening (on a module designed for touch and gesture) may be tolerable for programming a patch in a studio but it is not something anyone wants to do in the context of performance - it is programmer logic, not musician-friendly - counterintuitive, too slow and not gestural. Nevertheless, it is true that I had not figured this workaround out (indeed, a clock setting without a clock is also counterintuitive) and I will of course try the patch you've shared here when I get back to my pair of Glisses in the studio. I want to love them but have so far found them frustrating and more or less unusable except as a nice wonky LFO. I really hope user-feedback will create a significant software revision towards greater playability in future.

I realise I am breaking your balls in a public forum here, for which I apologise, but I hope you can also tell I am trying to help

Thanks for the feedback and sorry you feel so strongly about the UI. The minimal design comes at the price of the menu system. Alongside colour to guide you through the menus there are also animations which can be turned on which might help you. This means that every time you touch a selector you will see an animation played back on the sensor which shows the functionality of that selector. These were imagined as tool to help people with issues recognising colours. These are turned off by default. See the global settings section of the video for instructions on how to turn them on: 06:57

The color palette was limited by the properties of the PCB material used for the faceplate in the first production run: it blocks almost all of the blue light going through it, making blue and purple unusable and leaving us with red, orange, yellow, green and a flakey white, which admittedly is not the best palette to work with for someone with colour recognition problems. Luckily, for most of the elements of the menus the color of a selector is not meaningful and in order to browse most of the UI one can refer to the selector's position alone. The color only becomes meaningful for selectors 1 and 2 in the mode menu, where their color reflects the state they are currently in. One can enable "Menu animations" (8:17) so that changing a selector's state displays an animation of its new state. This can help both those users that struggle remembering the functionality associated with a color and those who have color recognition problems. I hope this helps.

Since it´s open-source, it could be realized via i2c and a separate push button module.

@kitkatandy929 while that is possible I see no reason why I would want to sacrifice hp just for a push button. Just slap it on the opposite side of the jacks and away you go.

I would have thought it would have a serial interface too.. With all those features it would be nice to be able to send and receive commands and values from another MCU... Nice unit

@@procactus9109 there is a spare I2C port at the back and a USB micro port, both can be used for future expansion, but there is nothing in the firmware right now except for the USB being used for firmware updates.

it is on some 🙂

@@oromoiluig it wasn't at that time.!😜

yes you can.

Timestretching can be achieved by resampling the output of a pitch shifter. E.g.: to double the duration do the following: - pitch up by one octave (2x frequency) - upsample the output by 2x - play back the upsampled output at the input sampling rate You can achieve arbitrary timestretching ratios by using fractional ratios in the pitch shifter and resampler. Keep in mind that constant-rate timestretching in real-time is kind of impossible or unusable because you either run out of input data if you are speeding up or start building up an ever increasing delay if you are slowing down.

No, you can just run gdb on the board. Ideally, you'd run it in a terminal while ssh'd onto the board, otherwise for quick and dirty trials you can run it directly in the console at the bottom of the IDE, keeping in mind the two caveats: 1) it has no readline support, and 2) text between < and > won't be displayed because of a bug in how the text is handled. If you need more help with this, search the Bela forum for gdb and/or post a new question there.