Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jun 29 20:40

    jcelerier on master

    [pipewire] Do not try to sync i… (compare)

  • Jun 29 10:52

    jcelerier on master

    [exprtk] Collect variables only… (compare)

  • Jun 22 22:13
    x37v commented #780
  • Jun 20 09:34

    jcelerier on master

    [math] Move safe_inf and safe_n… [exec] Fix merging of e.g. an a… (compare)

  • Jun 17 07:35
    avilleret commented #793
  • Jun 13 17:08

    jcelerier on master

    [merger] Fill with zeros for sa… [expr] Add a function to allow … (compare)

  • Jun 13 08:13
    jcelerier commented #793
  • Jun 13 07:06
    avilleret commented #793
  • Jun 12 15:50

    jcelerier on master

    [math] Add support for emscript… (compare)

  • Jun 12 10:27

    jcelerier on master

    [exec] Fix invalid rounding for… (compare)

  • Jun 08 10:07
    avilleret commented #792
  • Jun 08 07:06
    maybites commented #794
  • Jun 08 07:06
    maybites closed #794
  • Jun 07 07:06
    jcelerier commented #792
  • Jun 05 12:17

    jcelerier on master

    [ci] Forgot an include (compare)

  • Jun 05 10:54

    jcelerier on master

    [exec] Use a spinlock for execu… [scenario] Fix that callbacks w… (compare)

  • Jun 05 08:16

    jcelerier on master

    [exec] Replace the mutex in cal… (compare)

  • Jun 03 15:44
    jcelerier commented #794
  • Jun 03 15:44

    jcelerier on master

    [mac] Improve std::ssize detect… (compare)

  • Jun 03 14:32
    maybites commented #794
Pia Baltazar
@bltzr
"there is no user called @avilleret in this room"
maybites
@maybites
I am trying to nudge the developer of AudioOverOsc (https://git.iem.at/cm/aoo) to create a Max version (there are already pd-externals available). I know there are similarities between the two apps, but how hard is it really to write something like libossia and then make it work for both? Obviously it is doable, and are there some guidelines one could share? things to look out for?
Pia Baltazar
@bltzr
AFAIK libossia implementations in Max and pd are quite independent, and share very few common code apart from libossia of course
There are some frameworks for developing stuff from scratch for both Max and pd but one needs to do it from the start AFAIK
maybites
@maybites
I already though this might be the case..
is libossia's implementation for pd and max developed by the same person?
Vincent Goudard
@vincentgoudard
hey, sharing some thoughts here on a nasty problem. ossia/libossia#755
would love to hear what you think would be the best
Antoine Villeret
@avilleret
@maybites yes I developed both ossia-max and ossia-pd, @jcelerier made a great talk last week about some tools he made to help developer to make cross environment development (that is to say : write the binding code only once, then the core of the object is shared between pd and max)
this is not how ossia-pd and ossia-max are build, and I don't know yet if this tool might be easily used to port AudioOverOSC to Max
btw AudioOverOsc sounds like a dirty hack to me
maybites
@maybites
btw AudioOverOsc sounds like a dirty hack to me
it works quite well, though.
Vincent Goudard
@vincentgoudard
besides, what interesting technology did not start as a dirty hack ?
Jean-Michaël Celerier
@jcelerier
_o/
Evan Montpellier
@evanmtp
hey J-M
Jean-Michaël Celerier
@jcelerier
hi ! I was fetching and booting my laptop for zoom
Evan Montpellier
@evanmtp
cool!
I think it's a good idea to take minutes in here for sure
Jean-Michaël Celerier
@jcelerier
Navid
@navid
  1. Adding a namespacebrowser tester to the unit-test/test-patchers
Jean-Michaël Celerier
@jcelerier
this is the one with maybites' analysis of the combination of @mode, @default, and @recall_safe
Navid
@navid
  1. Finding a very simple solution for having messages and returns which never get saved and always remain invisible to all preset systems by default, forever. + documentation of these all within the embedded max-help patches
Navid
@navid
  1. getting ossia-max into the Package manager...
Navid
@navid
  1. Ossia models/modules should have a simple option for users to activate and monitor anything that comes out of them: so that they could, for example, wiggle a slider and see what its OSC structure is called. Evan demonstrated a strategic use of "ossia.remote //*" wild cards, which should be added to ossia.remote's help patch
Navid
@navid
  1. Unit-Tester for saving/recalling big hybrid osc strings: for example an entire OSC state of spat. Currently this is not possible easily. @evanmtp Evan can articulate exactly what is buggy or needdedd.
Evan Montpellier
@evanmtp
Hey @jcelerier! I'm going to take a look at #764 and #760. Just wanted to mention that I loaded some objects from 1.2.8 and got an error showing that they haven't been signed and/or notarized.
Screen Shot 2022-03-12 at 9.28.13 AM.png
(on macOS 11.4)
Jean-Michaël Celerier
@jcelerier
hey :)
hmmmm this is weird, notarization seems to have happened correctly from the git log..
regarding these two issues, I think that I understand the real deep issue: you want to be able to see which parameters were loaded when loading a preset right ?
right now the preset is applied, that is, the values are sent to every ossia.parameter
but I'm not sure there's an easy way to get this list of changes from a centralized place
Evan Montpellier
@evanmtp
Hey! Actually I'd say it's less about keeping track of which params changed, and more about being able to control which ones are stored
The main thing for the TML use case is really to guarantee that, for example bangs from some ossia.parameter @type impulse that's being used to get user input (e.g. mouse clicks) from an ossia.view don't fire every time a preset switches
or likewise that data that should be ephemeral (e.g. values from an accelerometer) being passed through an ossia.parameter @mode get aren't stored in presets
and this seems to be already in fact the way things are working as of 1.2.8, at least if you use "preset load/save" messages to [ossia.device]
Evan Montpellier
@evanmtp
As for #771, I was just trying to think of what would be needed to replicate this same behaviour with the "namespace" messages to [ossia.device]. This seems preferable for TML since (1) the roll-your-own preset system we're using (heavily derived from the example in the OSSIA overview patcher) is based around using this message and storing the output in a [dict],
and (2) being to be able to store the preset data in a [dict] and saving it with the patcher is a bit tidier than storing presets in external txt files
also it's nice that you can store multiple presets in a single [dict], since sometimes in the course of working on a project you can wind up creating tons of presets for a device and having loads of individual text files would be unwieldy
hope that clarifies the idea!
Jean-Michaël Celerier
@jcelerier
I wonder if storing the presets in dicts is something we could do directly from the c++ code as that'd likely be faster and simpler
(and seems like a nice feature for everyone to have)
Jean-Michaël Celerier
@jcelerier
@evanmtp everything going fine in the black box ?
Vincent Goudard
@vincentgoudard
hey there, I am currently writing an "extended asbtract" (as they say), to present the AIM-package (my libossia ersatz)... I looked for a paper on libossia but could not find one... is there any ?