• RT-Chris

    Amazing, that's really very helpful, thank you David! :raised_hands:
    I've been keen to explore beyond the standard lop, hip and bp too, so this will help a lot with that too. Yeah I'm beginning to understand the general idea of how it works, but implementing it is another thing. This will help a lot. One of those moments when I think I've learned enough to feel I've broken through to some kind of intermediate stage, and then... :frowning:

    posted in technical issues read more
  • RT-Chris

    Thank you, appreciate the link, and for feeding back about the Hadamard matrix. I guess there's no way around just having to learn how to read calculus if I want to work with filters... :persevere:

    posted in technical issues read more
  • RT-Chris

    I'm beginning to try to understand some basic reverbs from scratch. I know it's a huge topic, and at my level (not quite new to pd but no formal dsp education) I'm unlikely to get too deep into it unless I learn how to read algebra. I've looked at rev~1 + rev~2 to being with, but the reverb outlined in

    seemed decent and well explained. It helped me grasp the basics of what is going on to begin with, but I'm still struggling to know how to implement some aspects of it.

    It relies on "shuffling and inverting" multiple delay signals as an alternative form of an allpass, but I can't really understand how to variously invert multiples of a single delayed signal. Am I better off looking to the more standard allpass examples in the documentation H.15.phasor and passing the multiple delayed signals through this?

    There's also two matrixes referenced, the Hadamard and the Household, and wondered if anyone had any tips on how they work, what it might look like in PD...are the matrixes combinations of additions and subtractions of signals, like in the rev2~ reverb example?

    posted in technical issues read more
  • RT-Chris

    @romulovieira-me Under preferences > audio> select your sound card's line input. If it is the internal sound card there shouldn't be very many options, just a mic and maybe a line input (depends on your OS). Generally it's default set to the mic. (https://puredata.info/docs/faq/audioinput)

    Then in a patch, create an [adc~] object. Normally or initially, this is assigned to the mic on the computer, but if you have selected the signal line input from your soundcard you should be able to get a connection established. Getting the correct input and output set up can be the hardest bit of getting set up, stick with it and you'll find what is right for you. If you struggle with it, post a screenshot of your audio options and we can hopefully help point you in the right direction. If it's just a mono input, you may only have sound form one output of the [adc~] object. If you right click the adc object you can find out more, with examples etc. (you can do this with all patches, and is a great way to learn via practise.

    You will still have to connect the input sound to the [dac~] object, which will convert your signal back from digital to audio. Be careful though, it will be at full volume, so it is always recommended to put an object before the dac that will lower the volume (0 is silence, 1 is full volume, so lower decimals of 1 are advised before you know what to expect, maybe [*~ 0.1] to start).

    A small diagram to describe:
    {adc~]
    |
    {*~ 0.1]
    |
    [dac~ 1 2]

    explains how to do this if the audio input is selected as the computer mic, but if you change the selection you hopefully can find your guitar input (if you have an external sound card this will be a lot easier). Generally ASIO is recommended, as other basic sound cards can have very slow latency (particularly noticable if you're working with live physical instruments) and can crackle a lot too.

    It's worth searching this forum too, as you might find a lot more tips and help.

    posted in technical issues read more
  • RT-Chris

    Ah, I somehow missed this, @60hz thank you!!

    posted in technical issues read more
  • RT-Chris

    Hi All, I'm using GEM (very basically) but can't get that to display on a secondary display (despite the fullscreen msg in the help file - doesn't seem to work for me...), so have to run the GEM window from my main display and run my behind-the-scenes patch in the secondary display. Which works okay, but every time I go to open a patch or abstraction, it opens in my primary display (interrupting the GEM output window). Anyone have any tips as to how to offset where windows open, or ways of using secondary displays?

    posted in technical issues read more
  • RT-Chris

    Thanks @jameslo. I found int_fract~ an external which seems to parse signal integers from the fractal part of their float number, hopefully that will help.

    posted in technical issues read more
  • RT-Chris

    I'm not very familiar with using audio objects, but am trying to figure out a pulse train based on mixing a few different approaches from a few tutorials. I have something quite decent going, but seem to be getting this occasional creeping in of an incomplete phase cycle (see output of second wrap~ on right). No other signal is going in, yet I can't seem to see how this kind of half-cycle is creeping in. Anyone have any thoughts? I'm guessing something is happening between the samphold~ and the *~
    pulsar_click.png

    posted in technical issues read more
  • RT-Chris

    @jameslo Great, really impressive, thanks for sharing these! The octave divider inspired one is really impressive. I had figured out something vaguely like the sequencer example, just with threshold and tabread, but is v basic, this looks like there's plenty to unpack here, thank you!
    @kyro Yeah, thanks, been looking at autonomism and unpacking the patches, but couldn't find anything directly obvious. Was kinda asking in case there was something very obvious that I just had missed.
    @ddw_music thanks for this, I'll explore this and see what I can figure out from it.

    posted in technical issues read more
  • RT-Chris

    @whale-av Thorough and quick as ever, thank you David. I will have a look at the patch when I can.

    Might just be ultimately a dead-end to base things solely on signal rate if half-speed is the limit...phasor does just seem like a slightly unpredictible object, not quite reaching 0 or 1 with each cycle. I was drawn to how fluid its changes sounded, with Line~ being a bit less so, I guess thats down to the difference between sample and block-rate processing (I don't think I realised the importance of vline~ for sample-accurate processing...). Thanks again!

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!