• oid

    @MarcoDonnarumma This would most likely be an issue with either the package or your system, my self compiled copy of 50-2 had no issues with zexy, maxlib or iemlib from what I remember, certainly had no issues with sigmund~. I would download the source and compile, if that come out good and proper drop the package maintainer a note, if not the output of config/make will likely give you some answers, at least with the externals.

    posted in technical issues read more
  • oid

    [Until] followed by a counter is all you need, feed the counter into both [array gets] to set the index, feed the outputs of both arrays into the math of choice.

    posted in technical issues read more
  • oid

    @Marcelo-Carneiro None of those are the actual error, they are just the exit status of ld and make, you need to scroll up further to find the real error. Most likely a missing library since ld is involved, so double check you have all of pd's dependencies installed.

    posted in technical issues read more
  • oid

    Think some more context is needed, the patch itself would help, perhaps some info on what this sensor is as well. I am not quite understanding what you are trying to accomplish.

    posted in technical issues read more
  • oid

    @tiemget The [change] does what you need and no [spigot} needed.

    posted in technical issues read more
  • oid

    @jancsika I am not too concerned about it being accepted as THE standard library or anything, just using that as a guideline as to what should and should not being included. If I do go ahead with this I intend to get input from the dev-list, if nothing else they likely will be able to offer some valuable advice regarding the sorts of things which should and should not be included, or perhaps they will point out the reason such a thing does not exist for pd.

    posted in technical issues read more
  • oid

    @ddw_music I don't really see scope creep being an issue, but that is mostly because I am fairly skeptical that there will be enough support to even get a viable library together let alone one that is bloated and even if it did get fairly large, maintenance is not nearly as much of an issue with abstractions as it is with externals, worst case is they end up like list=abs, perfectly functional but outdated and inefficient by current standards. Either way, I am not going to worry too much about that until it becomes at least a vaguely dim possibility, the whole project is somewhat self limiting by way of my freetime and the community, I have no expectations of anyone else contributing beyond sharing abstractions, if I get it great, but I expect it will be mainly me going through them to give them a consistent style, commenting code, and writing help files and I really can't see bloat as likely. Ideally someone will step up and deal with the audio abstractions, I do not do much audio in pd and others can probably do it better, but I can muddle through for the cause if I must.

    posted in technical issues read more
  • oid

    @beem All of those basic questions are answered in many places, the manual, the help files, over and over on this forum and mailing list, on youtube tutorials, the floss manual, various books and many other places, it is all just a search away with the search engine of your choice. Why do you think they would go to the wiki instead of just asking here when they already have ignored so many other sources? We also need all the activity we can get, not to mention I often learn something from the resulting conversations.

    IRC is fairly dead, mostly announcements regarding people on the telegraph group which I know nothing about. Mailing list is about the same as the forum.

    posted in Off topic read more
  • oid

    @seb-harmonik.ar Nothing is wrong with that. I am only suggesting to extend what there is to offer the community, not replace it. There are many objects which do not really benefit from being an external and will likely never become a vanilla object, like a counter. A counter can be simple, but there are many ways to count, by one, by two, exponentially, backwards, by scale degree and on and on, these are the exact sorts of objects a standard library is perfect for. A few basic counters can be included and cover 90% of use cases and a good chunk of the remainder just need to copy the abstraction and make a minor change like adding an outlet. While externals and the interpreter are all about speed and efficiency in execution, a standard library (really any proper library made from a language extending itself through its own faculties) is all about speed and efficiency in coding, trouble shooting and reading.

    While I could just do it myself, it would not result in a well rounded standard library, it would just be a library for dealing with hardware synths since that is almost everything I do with pd. Most standard libraries are evolved by the community, even when the language specs the standard lib, real world use and the needs of the community ultimately dictate what is in there, the spec is just a starting point or guideline. For this to work it needs to be more than one person, people need to dig into the abstraction folders and find some potential candidates and offer improvements/ideas on abstractions, I can't do it all myself.

    So far it does not look like there is community support for such a project, but who knows, only been 12 hours so far.

    Edit: Fixed 4AM syntax and sentence structure.

    posted in technical issues read more
  • oid

    @seb-harmonik-ar all of those basic bread and butter things like various counters, adders, dividers, missing array functions like insert, some of the list-abs stuff updated to take advantage of [list store], anything commonly used. It will make things simpler to read and troubleshoot, especially when dealing with other people patches. That really is a big part of the whole purpose, we see the [declare] for stdlib and we know what is inside all those abstractions instantly, know they work and they reduce what needs to be read so that massive patch that someone needs help on is not as massive and less time needed to dive into subpatches and abstractions.

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!