love the whole look and feel of the new izzy, could never get it to work with maddmapper, now its just doing it....wonderfull, good stuff mark, happy to contribute and there's not to many products out there that that can be said of.
"network radio/broadcast" - I've been using vban(voicemeeter audio network) to create point to point audio tunnels and I think there's better functionality built into izzy so I'm sorry if this is my lack of knowledge but ... (relating to vban) I would prefer to be able to broadcast the audio without a static destination and pick it up in other machines without the need to specify the destination from the source (maybe I haven't looked hard enough, this may be a feature already
I don't know if this is exactly an audio feature.. but this is my biggest desire in Isadora.. *blush* sure I know I shouldn't rely on it so much but oh my please Mr. Coniglio:
milkdrop avs+spout (projectM) support built directly in to izzy (even as a plugin) - expandable with some of the advanced preset editing options in node format for non-programmer-peoples --even rudimentary controls to manipulate waveform size color sprite etc., Winamp works fine but it's no longer supported and adds overhead/cpu/gpu, potential vulnerability and could be streamlined without needing another application/spout/NDI Video connection ** and add DYNAMIC PRESET CONTROLLING right in izzy 🙏
having to click on the Winamp vis window then hit space/scroll/back just kills me - I've never found a workaround
I was running for the evil clowns the last couple of days, but I am back and managed to grap the file. I just tried it again and now it seems to work. I didn't change a thing in my project. But anyway, here is the file I used to test it. I can imagine that it makes finding the problem a bit difficult. Thanks!
@mark thankyou so much for this.. i was beating my head against the wall too and tried everything.. but yes this is a great solution.. i found some blurs that work great! especially a GLSL one that has tons of paramaters and isnt slowing me down noticably.. i really appreciate all that you do.
@bonemap Jacques, Fred and Bonemap, I have finally determined a workaround for being unable to save the large Isadora patch while editing. It is not related to having media on two different disks, as I thought, it happens when a background video is playing while I attempt a save or during an auto-save. This was an intermittent problem accompanied with one of two error messages(see attached). If I turn off the movie player and projector associated with the background video, I can save the patch. This is very strange because I have been saving a patch while a video plays to stage since I began using Isadora 12 years ago. This problem occurred on a 2017 Mac Book Pro, 2013 Mac Pro, and 3 different PCs.
Any idea of the ETA of Izzy3? and does the new pricing come into effect at the same time? I've got a bunch of students hooked on Isadora and the university wants to buy a license, but i recommended they wait until the new educational discount is in the system.
because it only shows the window if Isadora is the top application
Actually, you've identified a bug: if you untick the "Floating Stage Windows" after you've already shown the preview once, they will ignore the setting and still "float." However, if you restart Isadora with this box unticked, I'm 99% sure it will work. Give it a try.
@DusX, please add this bug to the sheet: "Name: Preview Windows Don't Update Configuration Once They've Been Shown" (This is because we're holding on to preview windows when they are hidden, to speed up the showing of many previews on Windows. This was to deal with the fact the Window/OpenGL context creation is so bloody slow on Windows.)
First of all, for anyone reading this who is using Mavericks -- please see [this link](http://www.enttec.com/support-center/kb/article/108-OS_X_Mavericks_(10.9)_-_IMPORTANT) -- as there seems to be a problem with the ENTTEC drivers on Mavericks.
One user reported that the only FTDI drivers that worked for him was version 2-2-18
You can get that version here:
You may also want to refer to their [installation guide](http://www.ftdichip.com/Support/Documents/AppNotes/AN_134_FTDI_Drivers_Installation_Guide_for_MAC_OSX.pdf) - especially the part that shows how to remove the old drivers. To do that, you need to do the following in the Terminal program.
sudo rm -r FTDIUSBSerialDriver.kext
sudo rm -r ftdiusbserialdriver.pkg
sudo rm -r ftdiusbserialdriverinstallerPostflight.pkg
sudo rm -r ftdiusbserialdriverinstallerPreflight.pkg
Let us know if this helps.
P.S. If 2.2.18 doesn't work, try the other drivers.
Started with "pushing particles.izz" to have mouse control X/Y movement of particles.
Then tried to use syphon receiver to bring in my Kinect IR stream from Processing (pushing particles + IR.izz). As you can tell Skulpture or DusX the second experiment isn't working. I cannot figure out how to tie it into the initial pushing particles patch and have the IR light take the place of the mouse.
Any pointers would be greatly appreciated.
recent and today's update in leap motion drivers leads us to some thinking in order to help Gego and other middleware to get data into Isadora (although an izzy actor in c would be the ideal thing because software like geco is using 27 % of an intel 2.7 ghz i7 with 16gb of ram under Maverick.)
Now. Geek osc version is just great we can write our own tags!
But the new version of leap motion driver is really stunning for a few reasons.
1) Leapmotion visualizer seems to overcome somehow crossing hands. If you switch hands horizontally your right hand is now left of screen but it is the right hand. And same for the left of course.
2) Turning a hand bottom up doesn't mixes fingers!!!! If you out right hand hand palm up now the thumb is in the right place.
3) And even better, It seems to be able to recognize what hand is in the field even if the hand is bottom up!!!!! Wow! Hands right thumb is still right thumb on screen even if right hand enters on the left end of the sensor's field of vision with palm up!!!!!!! I can see this because if I do this geco's right hand valus start to trigger.
Geco has a clever way to to this called dexterity detection. And it is good it stays that way for precision. But now everything seems right just out of leap driver.
In my opinion this means that leap people ttought the driver to recognize hands geometry in order to detect which it is and if it is bottom up or normal palm down.
As for geco I would suggest an option that ignores if fingers are open or closed. It would be just a “palm orientation” feature because otherwise you always have to be with spread fingers and cannotrelax or the contrary. Now, this can be avoided in geco addressing open and closed fingers to the same osc tags or midi channel and controller and then “linking the 2 modes (spread and closed) with the linking chain in geco. But it is quite a bit of work…
Now I’m dreaming…. And if geco could also receive midi or osc and have different preset in a same document. We could hand or sensor trigger diferent presets for different moments or funcions of the installation….. Maybe version 2?