What can be expected regarding being able to run Blynk along with standard WIFI features, initially:
Just getting started with Blynk, I’d like to incorporate it into existing sketches. Also curious about experiences with running addressable led animations.
Why? That can already be done in any ESP
Blynk is a GUI interface for IoT and also meshes with the ESP (just in case someone didn’t realise that 
)… thus no need to duplicate functionality that I can see.
Don’t forget the search option in this forum 
Thanks! I didn’t mean to use the features from ‘within blynk’ - I have been using these WIFI features before starting to use Blynk and I was curious if I can keep using them with Blynk, I have existing sketches with OTA, webupdating, UDP packet communication, and serving webpages, so I was wondering if I add Blynk to these sketches should it be expected that everything will still work the same. In general does using Blynk prevent any WIFI features from being used?
That depends on your coding abilities… Blynk is a library, and one that requires particular timing… as you probably know. Whereas many basic Arduino/ESP type programs assume they are all that matters 
So again, it all comes down to how well you can merge the two, and there is no one way… think turbocharging a stock engine… you don’t just bolt the two together, straight out of your local parts supplier, and hit the races right 
(well, perhaps you can… not me 
)
Thanks, yeah I know more about turbos than Arduino right now. I am not a coder by profession, I am sometimes lost in interpreting libraries. I use UDP to send packets between ESPs, would there be any problem expected with that? It seems to me the effect of Blynk.run(); to a sketch is to add a small delay while it performs communication and runs sketch functions as necessary, and everything else ESP WIFI related should work the same correct?
I don’t see why not, as long as everything meshes properly… I do know that many basic serial based links have issues, because they expect to have 100% of the devices time, listening for a possible incoming data byte… one that could be missed while the sketch is doing something else like processing a App command.
Well, it does maintain the “housekeeping”… I believe other stuff is automatically processed… but it is not adding delay for delays sake.
The issue is usually that other basic Arduino sketches tend to sit in the void loop() and run as fast as they can because that is all they do. But Blynk adds in a timing sensitive server based communications link to the App, and if the other programs are not correled properly (often needing to be reformatted and set into timed functions, usually via Blynk Timer) they will overrun and/or delay the timing needed to keep Blynk connected.
BTW, They are nothing mysterious. A library is really just a bunch of pre-coded routines that have been bundled up and set aside in a seperate file, to be easily “added” into your code via a single include command… instead of pasting in a whack of code that just overwhelms the whole, “now where did I put my LED blinking routine anyhow” search through your sketch 
There are also ways of doing this within Blynk ((Bridge) that may be neater than your current solution if you’re prepared to restructure the way that your code works.
Pete.