• whale-av

    @WEIRD1 I am sure that @lacuna has solved your problem.
    When you see that message it means that an object is receiving too many message parts, or the wrong message...... containing symbols instead of floats for example.
    So if you send [1 2 3( into [pack f f] you will see the error.

    In the console you should be able to right-click the error and it will highlight the object that is complaining in blue. That doesn't always work, but most of the time it does.
    I don't think that it is coming from your asdr though..... it looks ok.
    David.

    posted in technical issues read more
  • whale-av

    @jameslo I feel so bad..... :fearful:
    "Unfortunately when they are gone they are gone forever (until they come back)"...
    Harrison Ford.

    posted in this forum read more
  • whale-av

    @jameslo I agree....... it beats Columbo.... approaching an Agatha Christie level of intrigue today.
    So I took the time to do some research......
    India IPs.
    Will be gone this evening unless anyone is interested in its slow development.
    David.
    Capture.JPG

    posted in this forum read more
  • whale-av

    @chvolow24 [adc~] and [dac~ only work with a block size of 64. They control the timing for Pd and control messages are processed between blocks...... so we would have problems with other timed events like midi if that were not the case.

    If you put your external in a sub-patch blocked at 512 1 1 and keep your main patch un re-blocked then that should solve the problem, but you cannot have [adc~] or [dac~] in the sub-patch.

    A soundcard (dac + adc) will communicate with Pd and negotiate the buffer, but I imagine that the DAW will not do that with your external, if you are having problems with a blocksize of 64 (which is the standard for digital audio in most devices).

    If you are actually communicating with the DAW through Pds final output and input then you should probably increase the Delay setting in Pd Audio Settings.... rather than the block size.... if you need a bigger buffer.... https://forum.pdpatchrepo.info/topic/11834/pd-block-size-vs-audio-interface-buffer-size

    Or have a look at some of the VST externals that have already been written for Pd to see whether they have implemented somehow what you are looking for.
    David.

    posted in technical issues read more
  • whale-av

    @porres Ah..... I woke up this morning wondering if that would be the case. What is the chance that installing it and then setting a path to the library for Plugdata would work? Or do you think that it makes changes to the Pd binary?
    You obviously have much more experience of such things.
    David.

    posted in Off topic read more
  • whale-av

    @Carambolooo It is available for Linux...... https://github.com/ceammc/ceammc.github.io
    The help files you can compile from here..... https://github.com/ceammc/pd-help/blob/gh-pages/README.md
    David.

    posted in Off topic read more
  • whale-av

    @Carambolooo No need to be sorry...! We like to be able to help on this forum.
    You will soon be making fewer mistakes, well, maybe not....... we all make mistakes, but you will know how to fix them. Then, before you know it, you will be helping others.
    You will see in the link I posted that you can have more than one argument for an abstraction, and they can also be symbols, which can be very useful if for example different instances should load different files, or if you have given sends and receives names rather than numbers.

    And it might be useful to set your pan faders to 0.5, You can select "init" in their properties, set them all to 0.5, and save the patch. Then they will all be centered when you open the patch again, unless you have changed them. So a better solution is to give them a common receive name.... such as "pan" and send [s pan] a 0.5 triggered by a [loadbang] when the patch is opened.
    David.

    posted in technical issues read more
  • whale-av

    @Carambolooo You have forgotten to connect the right inlets of the [*~] volume controls for the effects channels.

    Here is an abstraction that will give you the [panner] objects........ panner.pd
    Put it in the same folder as your patch, then re-open your patch and for each instance give it an argument.
    ...... so in your patch change each [panner] to [panner 1] [panner 2] etc.....
    That will keep them separate..... each one will receive control messages from only the fader that you wish.

    Look inside [panner]. You will see at the top [r pan$1]. The $1 will take the argument you have just added to each [panner] as it is created.
    Before you continue you should get to grips with abstractions...... that will save you a lot of time as you develop your patches......... https://forum.pdpatchrepo.info/topic/9774/pure-data-noob

    You need to change all the hsliders controlling the pan to have a range of 0 to 1
    In fact all your sliders need to have a range of 0 to 1 (because audio values in Pd must be in that range) and you will have to change them all in their properties pop up window..
    You might well need to reduce the volume after your [catch~] objects as well because adding lots of [throw~] sends together will give you a final output greater than 1.

    As @benalb says...... we have no "multiply defined" problems in Pd.
    My best guess is that you have opened your patch twice..... effectively having each [catch~] then created twice in the plugdata program.
    David.

    Ps.... other parts of your patch could also be abstractions...... e.g.
    Capture.JPG
    You would create an abstraction...... say [mymix] and give that the argument for the channel number..... [mymix 5] etc.
    Inside it would look like this......
    Capture1.JPG
    ..... and [panner $1] would then get the same argument (5 in this case) from its parent abstraction.... its a sort of magic...... :wink:

    And adding a $0 to all the send and receive names would mean that you can open your [mixer] twice without cross communication and without any "multiply defined" errors.
    You could even include the control faders and VU's and show them through the GOP window of the abstraction...... another subject, but see the link above.......

    Expanding your patch would then be child's play rather than a lengthy process prone to errors.
    It's a lot to learn in one hit..... but well worth the effort...:exclamation:

    posted in technical issues read more
  • whale-av

    @alexandros Yes..... I am still undecided. The libpd link could be useful for the OP.
    The first two posts were a bit lazy and not very useful, but I don't see any malicious intent.
    I expect that the user (if not a bot) will let us know what is going on, but I still think he might add a backllnk for SEO to his profile once he has established a few useful posts and so built up some trust.
    That would be unusual..... usually they cannot be bothered...... and so I delete a few of them every week.
    David.

    posted in this forum read more
  • whale-av

    @ddw_music Thank you @ddw_music. I have been debating with myself whether to delete the posts or the user. The posts seemed to me to be too badly written to be generated by an LLM, and I couldn't figure out their purpose as the user has posted no backlinks in their profile.
    .
    I like the idea that AI engines will degrade by training on their own content though..... a very interesting perception....
    Maybe I will move them into a new thread.... "The future of AI, unable to recognise its own content"..... or simply "BOT heaven"...
    David.

    posted in this forum read more

Internal error.

Oops! Looks like something went wrong!