I am working on an old internal project. I am working on windows. The puredata I am using is on 32bit.
There are some objects like [mtx_*~] [mtx_:] [mtx_.^] [mtx_circular_harmonics] have "couldn't create" error.
I have iemmatrix installed through "find external".
I tried older versions of Puredata extended or several versions of vanilla. I can't create mtx_, either.
From pd/externals/iemmatrix, I can find a file called "mtx_0x2a0x7e.dll", which I think is "mtx_~" after decoding.
There is not much information on the internet about it anymore.
The "official" version (not the one with the 'extended' suffix) is compiled as a multi-object library. So you have to load the library first, either with a command line flag '-lib iemmatrix' or with a [declare -lib iemmatrix] object in your patch (The latter is much preferred as it makes your patch more portable). When loaded, iemmatrix prints a greeter to the Pd console window:
iemmatrix 0.3.2
objects for manipulating 2d-matrices
(c) 2001-2015 iem
IOhannes m zmölnig
Thomas Musil
Franz Zotter
compiled Sep 6 2019 : 12:07:54
After that you can create objects like [mtx_*~]
The version 'v0.0-extended' was added to facilitate the migration away from now retired Pd-extended. Since it is compiled as a one-object-per-file library and many of the those objects have names that cannot easily be used in filenames, Pd-extended used a trick with an additional hexloader library that translates hex encoded filenames to the actual name of the objects. For being able to load objects from the extended version, you would have to install and load 'hexloader' first.
Having said that, it is highly recommended to use the official version which is actively maintained while the extended version is not and is there for historical reasons.
Related
I am struggling to understand why the below code is throwing an error when it ran seamlessly about a year back. The code snippet is from a popular Coursera course. Does the Music21 package has some recent changes around stream.Voice?
data_fn = 'data/original_metheny.mid'
midi_data = converter.parse(data_fn)
melody_stream = midi_data[5] # For Metheny piece, Melody is Part #5.
melody1, melody2 = melody_stream.getElementsByClass(stream.Voice)
The error thrown is ValueError: not enough values to unpack (expected 2, got 0), which means there is no output for stream.Voice class when previously there were outputs for the same data (midi file). melody_stream.getElementsByClass('Measure') does show outputs.
Can you guide how to debug this?
Yes, one of the improvements in music21 v.7 is that files imported from MIDI now have a similar representation to files imported from MusicXML and other formats. Specifically, Parts now have Measures, which may or may not have Voices, rather than Parts directly containing Voices. Code should not depend on finding Voices directly contained in Parts, which is what this example was doing.
Instead, use this code to find all the measure-voices:
melody_stream.recurse().getElementsByClass(stream.Voice)
Or, equivalently, use the shortcut syntax in v.7:
melody_stream[stream.Voice]
Or, if you don't want the measures at all, call flatten() or chordify() depending on your use case.
What worked for me was downgrading music21 package to a version older than 7.x. So if you already have a newer version of music21 package installed, remove it using pip uninstall music21, Then install the 6.7.0 version using pip install music21==6.7.0.
I have created a model in Anylogic 8.3. Now I want to open this model on a different computer that contains an older version, Anylogic 8.2.3. This, however, does not work, as I am prompted with the fact that the model is created in a newer Anylogic version.
Is there a way to circumvent this issue?
I am not a system admin on the computer with the older Anylogic, nor does our license cover updating to a newer version of Anylogic (expired in december 2018).
You can easily do that by opening the .alp file of your model with Notepad or a similar text editor. Then:
Get your actual AnyLogic build version (open AnyLogic, click "Help" and then "About". You can find your build-version as in the image below
replace AnyLogicVersion and AlpVersion with your required values, e.g. something like AnyLogicVersion="8.2.3.xxxxxxxx" and AlpVersion="8.2.3"
save the file and open with AnyLogic 8.2.3
(Note that if you want to open a model in AnyLogic 7 that was developed in AnyLogic 8, you would also need to remove the entire <RunConfiguration> section. But this is not relevant in your case.)
I think it's only possible to go back to an earlier AnyLogicVersion by hacking the .alp if the AlpVersion is the same, because it denotes the structure of the XML. I don't have an 8.4 file handy, but I have, for example, an 8.5.1 and an 8.2.4, and the AlpVersion is 8.4.9 for AnyLogicVersion 8.5.1, but 8.0.4 for AnyLogicVersion 8.2.4.
If the XML structure is different, the newer version of AnyLogic will likely be unable to load the file. Looking at the two examples of essentially the same model that I've detailed above, there are readily apparent structural differences in the ActiveObjectClass, for example. If there are not too many structural differences, you could try replicating them. I've succeeded in doing that manually at least once, that I can recall.
There are a variety of online tools that allow you to compare the XML schemas of two XML documents, from which you will be able to judge whether a manual hack is feasible.
I am currently analysing movement data using the script provided by Lascelles et al (2016) in their paper "Applying global criteria to tracking data to define important areas for marine conservation". I have made some changes and additions to the script and now face the problem that the different packages needed do not work within the same version of R.
I am using the package "trip" which from what I can see works with >=3.2.5 but depends on spatstat which works with >=3.3.0. The script also uses the overlay function from the "sp" package, however this function has been deprecated, thus in order to run needs an older version of R (I have previously used version 3.0.3.
Is there a way to use multiple versions of R within the same project, or would I have to rewrite the script to avoid using functions that do not work within the same R version?
If you don't need any of the new functions/features introduced in the later versions of trip and spatstat I think you can just use the checkpoint package and install the versions from an earlier date. There is a nice vignette you can have a look at, but basically you just do something like:
install.packages("checkpoint")
library(checkpoint)
checkpoint("2016-01-01")
I have a question related to V4L-DVB drivers. Following the
Building/Compiling the Latest V4L-DVB Source Code link, there are 3 ways to
compile. I am curious about the last approach (More "Manually
Intensive" Approach). It allows me to choose the components that I
wish to build and install using the "make menuconfig". Some of these components (i.e. "CONFIG_MEDIA_ATTACH") are used in pre-processor directives that define a function in one shape if defined, and a function in another if not defined (i.e.
dvb_attach, dvb_detach) in the resulting modules (i.e. dvb_core.ko)
that will be loaded by most of the DVB drivers. What happens if there are two
drivers (*.ko modules) on the same host machine, one that needs dvb_core.ko with
CONFIG_MEDIA_ATTACH defined and another that needs dvb_core.ko with
CONFIG_MEDIA_ATTACH undefined, is there a clean way to handle this?
What is also not clear to me is: Since the V4L compilation environment seems very customizable (by setting the .config file), if I develop a driver using V4L-DVB structures, there is a big chance that it has conflicts with other drivers since each driver has its own custom settings. Is my understanding correct?
Thanks!
Dave
I am using this software called Simple Agent Pro, and it primarily uses TCL code. I was wondering anybody familiar with TCL or Sapro would be kind enough to tell me how to import the modules into the .tel file for Sapro.
When I try this:
package require tclOO.h
The program stops working.
Any help would be appreciated.
I don't know Simple Agent Pro at all, but if you're doing a “guerilla install” of TclOO then you need a few things:
Make sure you're using Tcl 8.5 (see what package require Tcl returns).
If you're using 8.4 (note: 8.4 EOLed this month), TclOO will not work at all (and it cannot be backported).
If you're using 8.6, it already provides the TclOO package and you shouldn't need to fuss around with all this.
Do a build of TclOO and install it to a location you prefer.
This will require Tcl's internal source files; TclOO explicitly pokes its nose into places where most code shouldn't.
You probably don't need to have a custom build of 8.5; just the configured sources somewhere will do. (You might need to hack the configure scripts a little bit.)
Add the location that you installed TclOO to to the search path inside your Tcl 8.5 program.
lappend auto_path /the_dir/you_put/it_in
If you're using Windows, it's probably easiest to use forward slashes for this path anyway (this is a directory name that is always highly protected before it hits the OS, so that's OK).
Now you should be able to require/use the package.
package require TclOO
oo::class create Foo {
# etc.
}
Note that the case and exactly how you write it matters. The version you get ought to be at least 1.0 (earlier versions were for development only) which corresponds exactly with the API as supported in Tcl 8.6 (modulo a few things that require 8.6 for other reasons, such as being able to yield inside a method which only works in 8.6 because that's where yield was first defined).
You probably mean
package require TclOO
Case and other stuff is important there.
Next time you should also include the stack trace. If the program stops working, it should display that either as dialog or on stdout.